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.