Re: 10.0

Поиск
Список
Период
Сортировка
От Josh berkus
Тема Re: 10.0
Дата
Msg-id 5737AB52.4070507@agliodbs.com
обсуждение исходный текст
Ответ на Re: 10.0  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 05/13/2016 07:18 PM, Mark Dilger wrote:
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.  It therefore makes sense to
> reserve room in the numbering scheme to be clear and honest about when
> backwards compatibility has been broken.  The major number is the normal
> place to do that.

The problem with that idea is that *minor* backwards compatibility
breakage is much more likely in each-and-every version than major
breakage is at any time in the foreseeable future.  The last major
breakage we really had was version 8.3, which if we'd been going by
compatibility should have been 9.0 (also for other reasons).

And if we adopt the "backwards compatibility" approach, then we'll just
be switching from the argument we're having now to the argument of "is
this enough breakage to rate a .0?  Yes/No?".  Which argument will be
just as long as this one.

So, my vote is now +1 to go to the 2-part numbering scheme.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parallel pg_dump's error reporting doesn't work worth squat
Следующее
От: Anderson Carniel
Дата:
Сообщение: Re: Losing memory references - SRF + SPI