Re: Release planning (was: Re: Status report)

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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