Re: [GENERAL] Backward compatibility

Поиск
Список
Период
Сортировка
От Igor Korot
Тема Re: [GENERAL] Backward compatibility
Дата
Msg-id CA+FnnTwSqDqcTb15QKjFCKLNzvapNKXdZ+W56fQEsV38pQJD1Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Backward compatibility  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: [GENERAL] Backward compatibility
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [GENERAL] Backward compatibility
Следующее
От: greigwise
Дата:
Сообщение: Re: [GENERAL] Bug in postgres 9.6.2?