Re: Release cycle length - Mailing list pgsql-hackers

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.

> We fix problems, but people must wait a year for the fix?

A couple points:
 (a) Critical problems can of course be fixed via point releases in     the current stable release series
 (b) As PostgreSQL gets more mature, the number of absolutely show     stopping features or bug fixes in a new release
gets    smaller. For example, I'd argue that neither 7.3 or 7.4 include     a single feature that is as important as
7.2'slazy VACUUM or     7.1's WAL. There are lots of great features, but the set of     absolutely essential new
featurestends to grow smaller over     time. I'd wager that for the vast majority of our user base,     PostgreSQL
alreadyworks well.
 
 (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
earlierin the release     cycle are properly thought out, and so forth.
 
     Note that whether or not we are using those 355 days effectively     is another story -- it may well be true that
thereare 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.

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

> People are not encouraged to provide small, well-thought-out,
> modular improvements.

I agree we can always do better when it comes to code quality. I think
the NetBSD team puts it well:
   Some systems seem to have the philosophy of "If it works, it's   right". In that light NetBSD could be described as
"Itdoesn't   work /unless/ it's right".
 

That said, I don't see how this is related to the release schedule. In
fact, one could argue that a longer release schedule gives new
features a longer "gestation period" during which developers can
ensure that they are well-thought out and implemented properly.

> Altogether, it's a loss for both developers and users.

I don't think it's nearly as clear-cut as that. Both types of release
scheduling have their benefits and their drawbacks. My main point is
really that a short release cycle is not an unqualified good (not to
mention that in the past we've been completely unable to actually
*execute* a short release cycle, making this whole discussion a little
academic).

-Neil