Re: 10.0 - Mailing list pgsql-hackers

On Fri, May 13, 2016 at 1:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Josh berkus wrote:
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
>
>> I think the next version should be 10.0 no matter what changes we put
>> in.
>
> Here's my two cents: we called 8.0 that on the basis of the native Windows
> port, and 9.0 that on the basis of getting in-core replication support.
> Both of those were game-changing features that deserved a "major major"
> version number bump.  But as the project matures, it gets harder and
> harder to come up with game-changing features in the span of a single
> release.  Parallel query is a great example: a fully mature parallel query
> feature would, IMO, easily justify a 10.0 moniker.  But what we have today
> is more like half or two-thirds of a feature.  If we call this release
> 10.0 on the strength of that, we could justifiably be accused of
> overselling it.  On the other hand, if we wait till next year when
> parallelism presumably will be much more fully baked, it'll be a bit
> anticlimactic to call it 10.0 then.  This isn't going to get better with
> other major features that can be expected to appear in future.  So we can
> expect to continue to waste lots of time debating the "what to call it"
> question, in pretty much every year except for the one or two immediately
> after a "major major" bump.
>
> There's also the problem that the current numbering scheme confuses
> people who aren't familiar with the project.  How many times have
> you seen people say "I'm using Postgres 8" or "Postgres 9" when asked
> what version they're on?
>
> So I think we should solve these problems at a stroke, and save ourselves
> lots of breath in the future, by getting rid of the whole "major major"
> idea and going over to a two-part version numbering scheme.  To be
> specific:
>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0.  Etc cetera.

+1

Any versioning system that removes subjective criteria is good.  These
debates in interminable and always have been.  Personally I would go
with something even more antiseptic like basing the version on the
year, where year is defined at the 'point of no return' -- going beta
for example.

merlin