Re: Prepping to break every past release... - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Prepping to break every past release...
Date
Msg-id 49B75B35.2050404@gmx.net
Whole thread Raw
In response to Re: Prepping to break every past release...  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Prepping to break every past release...  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)
Next
From: Nikhil Sontakke
Date:
Subject: gcc: why optimize for size flag is not the default