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

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-05-02 09:55:25

Doug Gregor <dgregor <at> osl.iu.edu> writes:
[...]
> I know. I, too, have a bunch of stable code on HEAD that is going to  
> be a pain to move over. To help ease this transition, I'll come up  
> with the appropriate "svn merge" commands to make it easy to pull  
> changes from HEAD into the development branch. Then, it should be  
> only a small matter to test them locally and commit them to the  
> development branch. If someone does cause problems with such a  
> commit, Subversion makes it very, very ease to revert those  
> changes... and we will.

Excuse me, but aren't we supposed to be moving towards Beman's new process?
If that's the case, I'm not sure I understand the way you're naming the future
subversion branches. The way I see it the current CVS HEAD will become svn
development, i.e. the place where things are allowed to break for short
periods; 1.34 on the other hand is going to become the starting point for the
svn stable branch, where commits are immediately backed out if they cause
regressions.

If I'm right then, while I understand Peter's concerns, I see no other way to
proceed; removing unstable stuff from HEAD sounds much more painful, if
feasible at all.

Given how long development on HEAD has gone forward with respect to 1.34 I
wonder if it wouldn't be a good idea to try and put together a schedule for
the merge of currently stable libraries, so as to ensure each lot doesn't
indeed cause any regression before the next one goes in. We could start with
the libraries that are already present in 1.34 and then move on to the newer
ones.

A tightly controlled approach might result in shorter delays, while avoiding
Jeff's stricter approach of leaving out of 1.35 any evolution of existing
libraries.

Cheers,
Nicola Musatti