Boost logo

Boost :

Subject: Re: [boost] A proposal for superproject structure and testing
From: Peter Dimov (lists_at_[hidden])
Date: 2013-12-09 18:42:08

Cox, Michael wrote:

> Changes in the develop branch correspond to changes that are intended for
> the *next* release...

The develop submodule branch will eventually become the next *submodule*
release. The master submodule branch is the current submodule release and
will eventually be part of the next Boost release. The boostorg develop
branch will (approximately) become the next Boost release. The boostorg
master branch is (approximately) the current Boost release.

The "latest" boostorg branch may or may not correspond to a Boost release.
There's no way to tell. Submodule develop->master merges happen
asynchronously with respect to the release cycle. This particular submodule
configuration may never be released.

> I'm assuming the criteria to merge a feature branch to the develop branch
> is that it builds and the unit-tests all pass with the current HEADs of
> the develop branches of all the other submodules.

That's very unlikely. One, nobody does a full Boost test cycle before
integrating work into develop, because a single compiler takes (I think) 8
hours or so, and you need at least two, if not more. Two, unit tests don't
just have to pass on a single compiler, and the test infrastructure doesn't
take "test my feature branch please" requests at the moment. So you have to
merge to develop in order to have the change tested on the full range of

In practice, our current workflow has been: you test locally on a few
compilers, merge (or push) into develop, wait three days to a week for the
tests to cycle, and if everything looks fine and nobody politely informs you
that their library suddenly broke, merge into master. Or forget to merge
into master, as the case might often be with svn.

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