Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
