Re: State of support for back PG branches - Mailing list pgsql-hackers

On Mon, Sep 26, 2005 at 09:27:28PM -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
> 
> >"Marc G. Fournier" <scrappy@postgresql.org> writes:
> > 
> >
> >>On Mon, 26 Sep 2005, Andrew Dunstan wrote:
> >>   
> >>
> >>>Maybe something like this would do: "We will attempt to maintain support 
> >>>of each major version for 3 years after its release, although this will 
> >>>not always be possible. After that time any major support requirement is 
> >>>likely to result in support being ended."
> >>>     
> >>>
> >
> > 
> >
> >>This sounds reasonable to me ... I think it is more then most software 
> >>projects do, isn't it?
> >>   
> >>
> >
> >To translate that into reality: 7.2 (2002-02-04) would be dead already,
> >and 7.3 (2002-11-27) will be dead around the time we are likely to
> >release 8.1.  
> >
> 
> It doesn't say we must drop it, it says we can after 3 years (or 1 
> release + 2 years if you like) without any troubles of conscience. ISTM 
> that we could and possibly should keep supporting it until it appeared 
> some major patch was required that was too much work or too dangerous.
> 
> Remember, many people don't want to jump onto a release right away - I 
> know of large enterprises that have a policy not to use the .0 version 
> of anything. So a 3 year cycle is more likely to be a 2 1/2 year cycle 
> in reality. Then factor in testing and migration time and the production 
> life in the field between deployment and end of life might be only about 
> 2 years. That's plenty short enough, especially as we still don't have a 
> nice pg_upgrade utility.

We started our upgrade from 7.2 to 7.4 about 20 months ago and finished it
about 10 months ago, skipping 7.3 entirely.

We've only just today hit our first problem in 7.4, and it's fixed by
upgrading to 7.4.current, rather than the 7.4.something we originally
upgraded to from 7.2.something.

We'll be skipping 8.0 completely and the next step will probably be to
8.1.something (or possibly 8.2.something, depending on how bizgres
looks in 3 months time). We'd probably consider upgrading our
customers more often, but a dump and restore is extremely painful.

Just a view from the pg-based-enterprise-application world.

A nice pg_upgrade utility would make a big difference. Clearly an
in-place upgrade is possible, but maintaining is hard. There are two
broad ways of running a pg_upgrade project - one that is entirely
independent of the main codebase and one that puts requirements on the
main codebase developers ("if you change $foo you provide code to
translate old $foo to new $foo"). Any feel for the relative difficulty
of the two approaches? And how much push-back there'd be on the latter?

Cheers, Steve