Re: Prepping to break every past release...

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.