Re: [GENERAL] Backward compatibility - Mailing list pgsql-general

From Igor Korot
Subject Re: [GENERAL] Backward compatibility
Date
Msg-id CA+FnnTwSqDqcTb15QKjFCKLNzvapNKXdZ+W56fQEsV38pQJD1Q@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Backward compatibility  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [GENERAL] Backward compatibility  (Igor Korot <ikorot01@gmail.com>)
List pgsql-general
David et al,

On Fri, Jul 21, 2017 at 12:00 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Fri, Jul 21, 2017 at 8:49 AM, Igor Korot <ikorot01@gmail.com> wrote:
>>
>> MySQL uses this:
>> https://dev.mysql.com/doc/refman/5.7/en/mysql-get-server-version.html.
>> Is it safe to assume that PostgreSQL calculates the version the same way?
>
>
> Yes and no.  Things are changing with this next release.  The next two major
> releases will be:
>
> 10.x  (or 10.0.x using historical nomenclature - 1000xx)
> 11.x (or 11.0.x using historical nomenclature - 1100xx)
>
> For prior releases the major versions are:
>
> 9.2.x
> 9.3.x
> 9.4.x
> 9.5.x
> 9.6.x
>
> If you want to consider the 9 to be "major" and the .[2-6] to be minor for
> mechanical purposes that's fine but the change from 9.5 to 9.6 is a major
> change with backward incompatibilities - which a minor change doesn't allow.
> In the new setup the thing you call "minor" will always remain at zero in
> order to eventually mitigate the need to have this kind of discussion. Since
> it is always going to be "0" we simply omit printing it.

I just need to split the version by ".".

But if the next releases will not increment second value and will
number the releases
as 10.0.0, 10.0.1, 10.0.2, then this schema won't work.

Thank you.

>
> David J.


pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [GENERAL] Backward compatibility
Next
From: greigwise
Date:
Subject: Re: [GENERAL] Bug in postgres 9.6.2?