Re: 10.0

Merlin Moncure <mmoncure@gmail.com>

From: Merlin Moncure <mmoncure@gmail.com>

To: Craig Ringer <craig@2ndquadrant.com>

Cc: Greg Stark <stark@mit.edu>, David G Johnston <david.g.johnston@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.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-17T13:24:35Z

Lists: pgsql-hackers

On Fri, Jun 17, 2016 at 1:01 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> 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.

Ugliness is a highly subjective qualifier.  OTOH, Backwards
compatibility, at least when the checks are properly written :-), is a
very objective benefit.

merlin