Re: 10.0 - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: 10.0
Date
Msg-id 59BE33FD-5A08-4662-AD77-FB0B90E06D5D@gmail.com
Whole thread Raw
In response to Re: 10.0  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
> On May 13, 2016, at 8:26 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Fri, May 13, 2016 at 10:18 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.
>
> ​​You started this sub-thread with:
>
> "If I understand correctly..."
>
> ​I'm not sure that you do...​
>
> Our scheme is, in your terms, basically:
>
> <major>.micro
>
> where <major> is a decimal.
>
> You cannot reason about the whole and fraction portions of the decimal independently.

There is no point in having them as separate parts of the version number
unless you can do precisely that.  If the only difference between choosing 9.7.0
vs. 10.0.0 is that you consulted a numerologist who moonlights as an astrologer,
then, yes, you can't tell anything from the first number independent from
the second.  I was simply arguing against the numerology/astrology approach
to version numbering.  The only other way out of the numerology/astrology
approach is the one Tom Lane suggested, and that you seem to support.

This whole conversation makes me think the community has done a poor job
of communicating the nature of the (major,minor) portion of the (major,minor,micro)
numbering scheme.  I always assumed it was more respectable that it now
appears to have been.

mark


pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: 10.0
Next
From: Anderson Carniel
Date:
Subject: Losing memory references - SRF + SPI