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

Tom Lane wrote:
> 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 ...

When I say add-ons, I am thinking of source code patches that are
avaiable as options to the standard subreleases. I agree we don't want
to change our current subrelease criteria.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073