Alvaro Herrera <alvhe...@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.
No confusion, no surprises, no debate ever again about what the next
version number is.
This is by no means a new idea, but I think its time has come.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
