Re: Prepping to break every past release...

On Wed, 2009-03-11 at 08:33 +0200, Peter Eisentraut wrote:

> 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.

Please remember I'm just the messenger, passing on client feedback. It
hasn't ever been my way to act this way, but the reality is that
difficult upgrades make for more consulting income. The cost to the
client is much higher because of re-test costs, difficulty in supporting
applications across different sites running different PG releases and
general delay.

We're getting very good at doing upgrades now...

> 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.

I agree with the need for a deprecation policy or approach to this
issue.

I think that particular deprecation policy was too strong, but where
possible, it would be good to have a way to avoid niggly changes of
behaviour. We have done that sometimes, e.g. sort_mem is now a synonym
for work_mem, just not consistently. An example solution might be a
parameter that allowed us to act like the previous release in some
aspects. A parameter for every behaviour change would be bad because
that's just another minefield to cross.

The first step is to record incompatibilities as they occur and record
them somewhere, so that people can say "that'll break my app". Often the
first people hear about these things is when we compile the release
notes, which is far too late either to complain or to fix.

> 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.

You know I would not agree to that.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support