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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
