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

All,

>>> There's some very good reasons for the health of the project to have
>>> specific release dates and stick to them.
>> Help me understand why?

We've cited this before, but here's the definitive paper on the subject:

http://www.cyrius.com/publications/michlmayr-phd.pdf
summary here:
http://robertogaloppini.net/2007/04/02/open-source-production-time-based-release-management/

Further evidence since then with Debian, Parrot, and several other
projects which have moved from feature-based releases to time-based
releases is that each release had just as many features despite the more
rigid time, and that contributors and users were far better able to
organize their lives around a defined schedule.  Thus, each person was
able to contribute more because they knew exactly when they had to do
it.  I don't know about you, but I personally work better when I have an
actual deadline.

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
scheduleserious 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.

For our contributors, it's a lot harder to get funding to do paid
contract work on features if you can't tell your sponsor when the next
release is coming out.

The alternative?  100% of the evidence I've seen is that feature-based
release cycles get progressively longer as the project gets bigger.
Eventually you find yourself only doing a release every 3.5 years, like
MySQL or Debian used to.  And your developers start leaving because they
never see the fruits of their contributions, and your users start
leaving because there's never anything new.

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*.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com