On Fri, May 13, 2016 at 1:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
+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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers