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

Note that I'm all for a long (2 year? or even 'indefinite') development 
cycle for a major release if we continue on with what has been happening 
more often lately, where stuff is back patched to the last stable release 
... there is alot of stuff that doesn't require a reload of the database 
(or initdb) that could very easily be backpatched ...

As Jan points out, its the 'small features that are done' that we've been 
griping about having to wait for, not the big ones which we know aren't 
done ...

The nice thing about doing something lke that is those small features 
would get a degree of testing happening in a live environment ...

On Tue, 13 Jul 2004, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Jan Wieck wrote:
>>> I think in the future we have to force all large features, those that
>>> probably need more than 6 months of development time, to be properly
>>> #ifdef'd. Then it wouldn't be that big of a deal to release more often.
>
>> Alvaro started out with ifdef's but it got too confusing and we all
>> agreed to just go with a normal patch.  He just hits too much code.
>
> I think the same would be true of almost any really large feature ---
> ifdefs all over the code base are just too much of a mess.
>
> To be honest I think that "releasing more often" isn't necessarily an
> appropriate goal for the project anymore.  Five or six years ago we were
> doing a major (initdb-forcing) release every three or four months, and
> that was appropriate at the time, but the project has matured and our
> user population has changed.  Look at how many people are still using
> 7.2 or 7.3.  One major release a year may be about right now, because
> you can't get people to adopt new major revs faster than that anyway.
>
> 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.
>
>             regards, tom lane
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664