Re: Time-based Releases WAS: 8.5 release timetable, again - Mailing list pgsql-hackers

On Sat, Aug 29, 2009 at 12:19 AM, Josh Berkus<josh@agliodbs.com> wrote:

> I'd think the advantages for our commercial adopters (who pay the
> salaries for many of the people on this list) would be obvious; if they
> know with a small margin of error when the next version of PostgreSQL is
> coming out, they can plan testing and deployment of their new products.
>  See Kevin's post; many companies need to schedule serious testing
> hardware months in advance, and every ISV needs to plan new product
> deployments up to a year in advance.  We bitch a lot in the community
> about the super-old versions of PG which commercial software is using,
> but our variable release cycle is partly to blame.

It also works on the other end - with time based releases you can also
schedule obsolescence. It is just as critical knowing when the
community will stop bug fixes and  security fixes when you are trying
to schedule major rollouts and planning product development.

Canonical (my employer) certainly believe in time based releases, and
that is one of the major reasons for the growth of Ubuntu and the
Ubuntu Community. We now use time based releases for almost all our
sponsored projects (some 6 monthly, some monthly), and are lobbying
various projects and other OS distributions to get into some sort of
cadence with releases so everyone benefits. It makes us happier
(especially when we are choosing what we can commit to providing
security updates for the 5 year releases), and our users happier, and
I think you happier with less support issues.

(In fact the one project I'm personally aware of that doesn't have
time based releases also has the worst reputation for bug fixes and
updates and caused us trauma because of it, so I'll be pushing to get
that fixed too :-P)

> Certainly our project experiences with "waiting for feature X" have all
> been negative.  The windows port never got into 7.4 despite holding it
> up 4 months.  HOT held up 8.3 for three to five months, depending on how
> you count it, in what I think everyone feels was our most painful beta
> period ever.  Most recently, we let HS/SR hold up 8.4 for 2 months ...
> and they still weren't ready.
>
> I would like to see us go to an annual release timeline in which we
> release in the same month every year.  Any time we say "variable release
> date" what it really means is "later release date".  We've never yet
> released something *early*.

Yes please.

You may even want to seriously consider shorter release cycles.
Tighter cycles can actually reduce stress, as people are less
concerned with slippage. With our projects on one month cycles, it
doesn't matter that much if a feature isn't good enough for a release
- it just goes out with the next months release or the one after if
you really underestimated the work. With longer cycles, the penalties
of missing deadlines is much greater which can lead to cutting corners
if people are not disciplined.

Of course, PG already has its own historical cadence to start from
where as we had the luxury of adopting time based releases at the
start or relatively early in development. For PostgreSQL, with the
regular commit fests you might end up to a similar process to GNU
Bazaar except with yearly major releases and 2 month development
releases, documented at
http://doc.bazaar-vcs.org/latest/developers/cycle.html. This is a
smaller project, but had to address a number of similar concerns that
PostgreSQL would have to so may be a good basis for discussion.

--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/