Re: Release cycle length - Mailing list pgsql-hackers

Neil Conway wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > First, if you develop something today, the first time users would
> > realistically get a hand at it would be January 2005.  Do you want
> > that?  Don't you want people to use your code?
> 
> Sure :-) But I don't mind a long release cycle if it is better for
> users.

Given that users can run whatever they like, it's not clear that a long
release cycle is better for users.

>   (c) As PostgreSQL gets more mature, putting out stable,
>       production-worthy releases becomes even more important. In
>       theory, longer release cycles contribute to higher quality
>       releases: we have more time to implement new features properly,
>       polish rough edges and document things, test and find bugs, and
>       ensure that features we've implemented earlier in the release
>       cycle are properly thought out, and so forth.

On the other hand, the longer you wait to release a new feature, the
longer it will be before you get your REAL testing done.  You don't want
to release something that hasn't at least been looked over and checked
out by the development community first, of course, but waiting beyond that
point to release a new version of PG doesn't help you that much, because
most people aren't going to run the latest CVS version -- they'll run
the latest released version, whatever that may be.  So the time between
the testing phase for the feature you implement and the version release
is essentially "dead time" for testing of that feature, because most
developers have moved on to working on and/or testing something else.

That's why the release methodology used by the Linux kernel development
team is a reasonable one.  Because the development releases are still
releases, people who wish to be more on the bleeding edge can do so
without having to grab the source from CVS and compile it themselves.
And package maintainers are more likely to package up the development
version if it's given to them in a nice, prepackaged format, even if
it's just a source tarball.

>       Note that whether or not we are using those 355 days effectively
>       is another story -- it may well be true that there are we could
>       make parts of the development process much more efficient.
> 
> Furthermore, longer release cycles reduce, to some degree, the pain of
> upgrades. Unless we make substantial improvements to the upgrade story
> any time soon, I wouldn't be surprised if many DBAs are relieved at
> only needing to upgrade once a year.

But DBAs only "need" to upgrade as often as they feel like.  Any
reasonable distribution will give them an option of using either the
stable version or the development version anyway, if we're talking about
prepackaged versions.

> > The longer you develop, the more parallel efforts are underway, and
> > it becomes impossible to synchronize them to a release date.
> 
> I think this is inherent to the way PostgreSQL is developed: Tom has
> previously compared PostgreSQL release scheduling to herding cats :-)
> As long as much of the work on the project is done by volunteers in
> their spare time, ISTM that coordinating everyone toward a single
> release date is going to be difficult, if not impossible. The length
> of the release cycle doesn't really effect this, IMHO.

Linux, too, is done largely by volunteers in their spare time.  Yet
Linux kernel releases are much more frequent than PostgreSQL releases.
One difference is that the Linux community makes a distinction between
development releases and stable releases.  The amount of time between
stable releases is probably about the same as it is for PostgreSQL.  The
difference is that the *only* releases PostgreSQL makes are stable
releases (or release candidates, when a stable release is close).
That's something we might want to re-think.


-- 
Kevin Brown                          kevin@sysexperts.com