Re: [boost] A proposal for superproject structure and testing

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 
compilers.

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.