Re: [boost] [1.36.0] Release schedule set

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2008-05-24 03:23:23

Peter Dimov wrote:
[...]
> Yep. This is how things were intended to work. The question is whether we 
> need to reevaluate that. The single branches/release presupposes that only 
> one release is active at a time. Given the proposed schedule, this can only 
> be true if we drop the .1 releases. If we don't, it might be wise to revisit 
> the old practice of using a separate branch for every release family - 
> release_1_35, release_1_36, and so on. It might also be interesting to give 
> the "starting point" question another look. I think that the trunk is quite 
> competitive as a starting point for 1.36, because it is currently being 
> integration tested, whereas release+merges is not. 

The discussion in this thread resembles the one about which branch 1.35 
was to be based on. Although the much shorter delay makes it a smaller 
problem, a "runaway" trunk is still a problem. Given how cheap branches 
are in svn I don't think it makes much sense for trunk to be the sort of 
anarchic playground it appeared to be at times in the past.

In my opinion all releases should be based on trunk and branched 
immediately before the first release candidate is issued. Most 
development activity should take place in specific branches that are 
merged to trunk at appropriate times. For instance immediately after a 
release branch is created would be a perfect moment to merge new 
libraries in.

Whether point releases take place would depend on the availability of 
fixes and of release management voluntaries, but making them should be 
as simple as possible.

This is more or less how it is done for gcc, and it appears to work for 
them.

Cheers,
Nicola
-- 
Nicola.Musatti <at> gmail <dot> com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/