Re: 10.0

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: 10.0
Дата
Msg-id CABUevEyDYamAVBoi7pdBWr+hY2fh76x8RU9xZxo5pwsN=Hk-Cw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 10.0  (Dave Page <dpage@pgadmin.org>)
Ответы Re: 10.0  (Dave Page <dpage@pgadmin.org>)
Список pgsql-hackers
On Fri, May 13, 2016 at 5:29 PM, Dave Page <dpage@pgadmin.org> wrote:
On Fri, May 13, 2016 at 4:23 PM, Thom Brown <thom@linux.com> wrote:
>
> Well, one potential issues is that there may be projects which have
> already coded in 9.6 checks for feature support.

I suspect that won't be an issue (I never heard of it being for 7.5,
which was released as 8.0 - but is smattered all over pgAdmin 3 for
example) - largely because in such apps we're almost always checking
for a version greater than or less than x.y.

I imagine the bigger issue will be apps that have been written
assuming the first part of the version number is only a single digit.

If they are, they are already broken by design. But more to the point, unless you're arguing for *never* changing to 10.0, that's not really something that should decide when we do it, because they will break.

We have provided multiple ways to check this. For example, we've had PQserverVersion() since forever which returns an integer that you can just compare. We have never claimed that it would be single digit in any of the fields (first, second *or* third). I honestly don't care at all if those applications break.

(We would, however, have a problem to go above 100 in all fields *except* the first one, since the integer uses a two-digit representation for each)


--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: 10.0
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0