Re: [boost] 1.35 release approach (was [1.34.0] Deadline)

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-05-02 18:30:17

Doug Gregor wrote:
> On May 2, 2007, at 8:37 AM, Peter Dimov wrote:
> 
>> David Abrahams wrote:
>>> on Tue May 01 2007, "Peter Dimov" <pdimov-AT-mmltd.net> wrote:
>>>
>>>> Jeff Garland wrote:
>>>>
>>>>> BTW, I don't know if this has been discussed much, but the plan for
>>>>> subversion switchover, as I understand it, is to take 1.34 as the
>>>>> svn HEAD and force all work unstable stuff on the CVS HEAD to be
>>>>> brought over using the new process.
>>>> That would be very impolite. :-)
>>> I'm not sure this transition *can* be a "polite" process if it's  
>>> going
>>> to work.  That said, I'm open to suggestions.
>> Let me get this straight... you will be throwing all of my  
>> post-1.34 changes
>> away with the transition? What are the expected benefits of this move?
> 
> The current CVS HEAD would go into a branch in Subversion (say,  
> branches/post-1.34-head). The 1.34.0 release branch would become the  
> development branch. Of course, developers will need to merge changes  
> over from branches/post-1.34-head to the development branch.

I thought the current head was to go in devel?

> 
> Yes, it's a pain. However, my experience with managing the 1.33  
> release series (and watching the 1.34 release series) tells me that  
> this is the right way forward. With each release, effort has gone  
> into bug-fixes for the release branch while HEAD has become the Wild  
> West, literally falling apart in the interim. It took months of  
> stabilizing HEAD to get to the point where we could branch the 1.33  
> release, many more months to to re-stabilize HEAD for the 1.34  
> release, and the time is proportional to the time that the release  
> branch is active. How long will it take to stabilize HEAD post-1.34?  
> If we're going to break the cycle of longer and longer releases, we  
> need to start each release from a clean slate... which means, in this  
> case, starting from the previous release and carefully merging  
> changes over from post-1.34-head to the development branch.

That isn't at all what I had in mind. Rather, a release, say 1.35 would 
start with the previous release - 1.34 in this case. Developers, who 
have been working in devel (which is equivalent to the old HEAD), 
branch/tag their code at the point they think it is OK as "stable". Then 
when it comes time to do a release a script run by the release manager 
tries to merge code for the library from "stable" to the release 
candidate branch (working in library dependency order, with cycles 
broken when necessary). Tests are run. If there are failures, the script 
reverts the broken library, and moves on. We might do something like 
give developers a fixed period of time (a week? 10 days?) to fix 
"stable", but when the merge/test/revert-if-needed script is run again, 
any libraries that are still failing don't make it into the current release.

That procedure would preserve all of Peter's and other developers hard 
work in HEAD, and that work would go into 1.35 as long as it passes the 
regression tests.

--Beman