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

On Tue, Sep 8, 2009 at 7:54 PM, Andrew Dunstan<andrew@dunslane.net> wrote:

> The release cycle is quite independent of the release lifetime.

If you have dates on releases, it is easier to set dates on release
lifetime. If you know the releases come out once a year at about the
same time, and you want to have a set number of versions in play, you
can state at release time when the community will stop support. This
gives everyone a clear picture to people what versions they should be
targeting and when upgrades will be required.

> In any case, I don't accept this analogy. The mechanics of a Linux
> distribution are very different from the mechanics of a project like
> PostgreSQL. The prominent OSS project that seems to me most like ours is the
> Apache HTTP project. But they don't do timed releases AFAIK, and theirs is
> arguably the most successful OSS project ever.

We find it works for stuff other than Ubuntu too. IIRC original
concerns where you could do it for a small open source project,  but
it would be impossible to do when juggling as many moving parts as a
Linux distribution. You might find the document I cited is for a
project with similar issues to PostgreSQL and may address your
concerns. It seems to work for other large projects too, such as
Gnome, as well as smaller ones. People are discussing switching for
reasons Joshua cited (maintaining momentum, planning, enterprise
adoption etc.), because people find it a good idea on other projects
they work with, or maybe because they read too many articles on agile
and lean development practices. It seems to be working fine for me
personally (I work on launchpad.net, which is an Open Source
mostly-web  application using generally Lean/Agile development
methodologies, a one month release cycle and a team of about 30 spread
over all timezones).

> I'm especially resistant to suggestions that we should in some way
> coordinate our releases with other projects' timings. Getting our own
> developers organized is sufficiently like herding cats that I have no
> confidence that anyone will successfully organize those of a plethora of
> projects.

I tend to think it will evolve naturally as more people switch to time
based releases. Its natural to sync in with the OS releases your
developers care about because it makes their lives easier, and its
natural for the distributions to get in sync too because it makes
their developer's lives easier. But only hindsight will tell of course
:-) With a yearly schedule, it probably doesn't matter much except for
distributions with a 2 or 3 year cycle - you would still end up with
latest PostgreSQL a maximum of I think 8 months after the official
release.

> I am not saying timed releases are necessarily bad. But many of the
> arguments that have been put forward to support them don't seem to me to
> withstand critical analysis.
>
> I would argue that it would be an major setback for us if we made another
> release without having Hot Standby or whatever we are calling it now. I
> would much rather slip one month or three than ship without it.

This is why you want your cycle as small as possible - if you have a 6
month cycle for instance, the feature would be available a maximum of
6 months after it is ready. With the feature based release cycle, what
if it still isn't ready for prime time after three months of slippage?
Having one feature slip hurts, but having all features slip hurts
more. Josh cited several examples where he felt similar situations had
hurt PostgreSQL development. Of course, if you think it is critical
enough you can let it slip and if it is critical enough people will
understand - we let one of the 10 Ubuntu releases slip once and people
generally understood (you want to get a LTS release right since you
have to live with your mistakes for 5 years). There was some flak but
we are still here.

I personally suspect PostgreSQL would want a 1 year cycle for major
releases while a full dump/reload is required for upgrades. When this
changes, 6 or even 4 months might actually be a good fit.

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