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

On Tue, 2004-07-13 at 13:03 -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

It sounds like your only taking the point of view of people upgrading
previous installations. What about new installations? I'm sure there are
hundreds, if not thousands of new installations happening every week.
These people are going to grab the latest stable version without a
doubt.

I think releasing more often would result in features getting tested
much more. Then the "big installations" can see that a major feature has
been in two stable releases (even if the time period was only a year)
and feel much more comfortable in upgrading. Why would they have to
upgrade more often then necessary anyways? Assuming security exploits
are back ported of course.

--
Mike Benoit <ipso(at)snappymail(dot)ca>