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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers