Re: [boost] Re: [1.33.0] Release schedule suggestion

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-04-03 09:25:42

On Sat, 02 Apr 2005 21:30:10 -0700, Victor A. Wagner Jr. wrote

> I'm suggesting that we tag (with a branchable tag) the freeze point. 
>  If you're going to work on stuff not going in 1.33 commit your 
> changes on a branch that you make from there.  After the release,
>  merge all your stuff back onto the main branch.  This way, all the 
> developers (and testers) working on the release continue as normal.

I think I'm with Peter and Victor on this.  I too, end up merging all my
branch changes immediately to the main branch -- so the current process is
leading to more work during post-branch release phases.  However, as I recall,
this process came about because of a 2 factors: 1) lack of discipline by
developers and 2) the length of time required to complete the release.  The
past couple releases have proven that branching didn't improve discipline.  So
the message needs to be clear to developers -- don't try to rush last minute
stuff into the release -- do changes on a branch and wait until the release is
done.  

For this release I don't believe we have any 'must-have' features that will
perturb the schedule.  For example, if ptr_container, wave, or hash don't
stabalize by the freeze date we should remove them from the release instead of
holding the release schedule.  New libraries are easy to remove since they
don't have any dependent libs yet (yes I know about the hash --> multiindex
relationship).  Also, I'll say it again, we need to stabalize and freeze and
fix the 'core libraries' (type traits, test) immediately so that we can sort
the real failures from the induced failures.  When Boost.test is yellow or red
on every compiler (as is currently the case) it makes it difficult to tell if
the other libs are really broken or it's just a Boost.Test problem.  In
addition, changes in these core libs will slow regression tests because
virtually everything has to recompile when there are check-ins in these libs.

Jeff