On 9 December 2013 12:16, Peter Dimov
To expand on what I said in a previous message, I suggest the following structure for the superproject:
- branch "latest": automatically tracks "develop" of submodules (scripted). - branch "develop": automatically tracks "master" of submodules (scripted). - branch "master": contains either the last release or the current release candidate.
(This naming reflects a gitflow model. An alternative would be to use the more traditional unstable/stable for latest/develop.)
I'd rather use the alternative names. It's a bit confusing to have a "develop" branch which doesn't have "develop" submodules.
Test runners test all three, in sequence.
I like that this fits our current capabilities. But I worry about the increased demand of running three branches, the tests were already cycling pretty slowly with just two branches. I suppose we wouldn't need to run master until the later stages of a release cycle, which might help.
Release preparation starts with a gitflow release branch from boostorg:develop. The release manager then runs local tests and, if necessary, applies fixes on the branch by downgrading submodules to an earlier version or asking the submodule maintainer to resolve a problem and then upgrading the submodule to the later version.
I think that task would need to be shared out amongst more than one person. It shouldn't be too hard to coordinate with an online spreadsheet or something similar.