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.