Re: Prepping to break every past release...

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Prepping to break every past release...
Дата
Msg-id 49B75B35.2050404@gmx.net
обсуждение исходный текст
Ответ на Re: Prepping to break every past release...  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Prepping to break every past release...
Список pgsql-hackers
Simon Riggs wrote:
> The most consistent negative feedback I receive about Postgres is that
> we make minor changes from release to release that make it extremely
> difficult to upgrade without re-testing the applications. So we write
> great software, then make it difficult for people to upgrade to it.

Then I would maintain that part of that makes the software great is that 
we have the ability to make incompatible changes once in a while, 
avoiding the accumulation of cruft.  We do maintain old releases for 5 
years as compensation.

I did propose a deprecation policy that would address your concern to 
some degree by issuing warnings in release N-1, so the testing after 
upgrade can be taken care of for the most part by hunting down these 
warnings while running the previous release.  That didn't receive 
universal support, but I think we should still look for a compromise in 
that area.

The argument against was that this would slow down PostgreSQL 
development too much.  And note that the one-year major release cycle of 
PostgreSQL is already pretty much the shortest one of any software of 
this complexity.

So everyone has different expectations, it seems.


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

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)
Следующее
От: Nikhil Sontakke
Дата:
Сообщение: gcc: why optimize for size flag is not the default