Boost logo

Boost :

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


Nicola.Musatti <at> gmail <dot> com

Boost list run by bdawes at, gregod at, cpdaniel at, john at