Re: Release planning (was: Re: Status report) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Release planning (was: Re: Status report)
Date
Msg-id 17169.1089739632@sss.pgh.pa.us
Whole thread Raw
In response to Re: Release planning (was: Re: Status report)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Release planning (was: Re: Status report)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Of course this all ties into the pain of having to dump/reload large
>> databases, and maybe if we had working pg_upgrade the adoption rate
>> would be faster, but I'm not at all sure of that.  We're playing in
>> a different league now.  Big installations tend to want to do
>> significant amounts of compatibility testing before they roll out
>> a new database version.

> I think the only downside to a longer release cycle is that features
> developed would take longer to get out to the public.  Perhaps we need
> to start thinking of add-ons to existing releases such as an ARC or
> vacuum-delay add-on to the 7.4.X release.

Mmm ... for people whose pain-point has to do with compatibility
testing, adding features in minor releases would turn them into major
releases, because they'd still have to wonder whether the new version
would break anything.  I think our policy of "only bug fixes in stable
releases" is important to maintain, because it makes it easy for people
to upgrade within a stable release series.

Also, we do not really have the manpower to test multiple concurrently
developed versions ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Assisting developers
Next
From: Bruce Momjian
Date:
Subject: Re: Release planning (was: Re: Status report)