Re: 8.4 release planning

On Tuesday 27 January 2009 19:04:49 Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote:
> >> We have tried the short release cycle before, it was called 8.2. It
> >> fails, remarkably.
> >
> > I think this is a bit of revisionsit history.
>
> JD got the release number wrong, it was 8.3, but otherwise there's no
> revisionism involved:
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00786.php
>

The revisionism was that of "remarkable failure". That was our shortest
release cycle in the modern era. And it didn't have the advantage of the
commitfest process.

But I think what is important here is to recognize why it didn't work. Once
again we ended up with large, complex features (HOT, tsearch) that people
didn't want to wait 14 months to see if they missed the 8.3 release. And yes,
most of these same arguements were raised then... "full text search is killer
feature", "whole applications are waiting for in-core full text search", "hot
will give allow existing customers to use postgres on a whole new
level", "not fair to push back patches so long when developers followed the
rules", "sponsors wont want to pay for features they wont see for
years", "developers dont want to wait so long to see features committed", and
on and on...

The more I think about it, the more I feel that where we failed for 8.3 was
not having a short 8.4 cycle lined up, which would give more freedom to bump
patches to the next release.

> The theme that our release cycles are too long is not exactly new,
> of course, eg
> http://archives.postgresql.org/pgsql-hackers/2000-05/msg00574.php
> http://archives.postgresql.org/pgsql-hackers/2001-06/msg00766.php
> http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php

Yeah, I remember all that, and I think you'll find that I mostly was on the
other side of this issue :-)

But many of the arguments from back then don't apply any more. Remember when
you couldn't depend on pg_dump giving you dumps in the right order? Now that
was a recipe for painful upgrades. With things like Slony, it's now possible
to upgrade a majority of the Postgres installations with extremely minimal
downtime. (And yes, I happen to have one that wont work with slony, but
hey...)

> but by now I think we've learned to stop banging our heads against
> that particular rock. One-year major cycles work for this project,
> shorter ones are wishful thinking.
>

Do they? 1 year cycles certainly don't solve the problem of being left with
big/complex left over patches. They don't decrease the amount of time (as a
percentage) we spend in freeze/beta/release mode. And we don't even get them
out in 1 year; this 1 year cycle looks like at least 15 months.

--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com