Re: The case for version number inflation

>> We've always picked version numbers after we had the feature list.  What
>> features do you feel are on the fence?  I had the impression that
>> logical replication, for example, was pretty far from being done.
>
> I think we need to avoid making decisions based upon impressions and
> spend more time looking at facts, but that is beside the point.

Who's making decisions?  AFAICT, you and Andres have made most of the
descisions on SLR to date.  I haven't been involved, and am unlikely to
become so, unless SLR reaches the stage of doing beta testing.  So I'm
really unclear on what you're accusing me of, or why you are doing it.

> Actually, I wasn't talking about logical replication at all.

So what features were you talking about?

> It should be incompatibilities or major architectural changes that
> drive this, not simply new features.

That hasn't been our approach in the past.  While I can certainly see
arguments in favor of that approach, I can also see arguments against
it.  Now that we have pg_upgrade, there's an argument to be made that
any series which is pgupgradeable should have the same first version
number, for example.  On the other hand, we've generally done well in
adoption by using the first digit to advertise the presence of major new
features.

I'll also point out that the features mentioned above would almost
certainly require major architectural changes, so these things tend to
go hand-in-hand.  Adding pluggable storage or a pluggable parser would
break a lot of stuff.

> And I think we should actually plan things ahead of time, so we can
> save up lots of incompatibility patches and apply them all in one
> release at the start of the cycle. Block format changes, syntax
> changes, behaviour differences etc.

What changes have we even discussed on -hackers which would affect any
of these things?  To date, the items we've discussed which would
actually affect the file format turned out not to.

> Numbering the release once we've seen what's in it doesn't help planning at all.

It's what we've always done.  If you think a different system would be
better, please outline it.  However, this project has never done well
with requiring specific features for specific releases, so any approach
which implies that is going to meet a lot of argument.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com