Re: 10.0
Craig Ringer <craig@2ndquadrant.com>
From: Craig Ringer <craig@2ndquadrant.com>
To: Greg Stark <stark@mit.edu>
Cc: David G Johnston <david.g.johnston@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, Merlin Moncure <mmoncure@gmail.com>, Josh Berkus <josh@agliodbs.com>,
Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Dave Page <dpage@pgadmin.org>, Thom Brown <thom@linux.com>, David Fetter <david@fetter.org>,
Jim Nasby <Jim.Nasby@bluetreble.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2016-06-17T06:01:31Z
Lists: pgsql-hackers
On 17 June 2016 at 08:34, Greg Stark <stark@mit.edu> wrote: > So we would release 10.0.0 and 10.0.1 and the next major release would be > 11.0.0. > > This would have two benefits: > > 1) It emphasises that minor releases continue to be safe minor updates > that offer the same stability guarantees. Users would be less likely to be > intimidated by 10.0.1 than they would be 10.1. And it gives users a > consistent story they can apply to any version whether 9.x or 10.0+ > And matches semver. > 2) If we ever do release incompatible feature releases on older branches > -- or more likely some fork does -- it gives them a natural way to number > their release. > Seems unlikely, though. I thought about raising this, but I think in the end it's replacing one confusing and weird versioning scheme for another confusing and weird versioning scheme. It does have the advantage that that compare a two-part major like 090401 vs 090402 won't be confused when they compare 100100 and 100200, since it'll be 100001 and 100002. So it's more backward-compatible. But ugly. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services