Re:[boost] Re: 1.32 release preparation

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-06-27 22:45:32

On Sun, 27 Jun 2004 19:05:45 -0700, Robert Ramey wrote

> Personally I think the concept of scheduling a release fundamentally 
> flawed. I would suggest another idea.

Gee, I couldn't disagree more.  In my mind, it is simply a time versus
functionality tradeoff.  Unlike typical project development since boost
releases don't have a 'required' set functionality, we should be able to set a
date and stick to it.  Anything that doesn't make it in time is tossed out,
period.  I can even imagine taking a much harder line than is done currently
by allowing the release manager to roll back any library that has seriously
regressed or is causing problems.  It will still take a month to run through
all the various issues that come up, but it should be much more bounded than
past releases.
 
> a) the release manager or the core influential developers keep an 
> eye on the current state of the CVS tree and tests.  b) When things 
> look "pretty good", branch for release without warning.  None of 

The problem is that this may never happen without prodding for a release date. 
 
>...snip...
> Under this system, releases would occur more frequently - on the 
> order of 6 weeks.  

I would be fine with more frequent releases, but there is apparently a
substantial amount of work to perform the release function (I don't have first
hand experience, I'm just guessing this is true from the comments of folks
that have).  So the problem is we need more people to perform this task if we
want to release more frequently.  Of course, these are the same people that
are often the same people that are writing and libraries -- so if we release
more we might review less, etc.  Of course the process can be more scripted,
etc, but that takes someone to do it as well.

Jeff