On Mon, Dec 9, 2013 at 5:16 AM, 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.)
Test runners test all three, in sequence.
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.
Ideally, this release branch should be tested non-locally. However, in the past switching branches for testing has proved a problem. Therefore, the procedure continues instead with:
When the release manager is satisfied with the local test results for the release branch, he merges it to master. This becomes a release candidate. If tests prove satisfactory, the release candidate is tagged as an official release and the release branch is deleted. If not, work continues on the release branch.
I'm not sure I understand the need for a "latest" branch for the cross-linking of the superproject's develop branch with the submodules' master branches. 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. If that's the case, shouldn't the superproject's develop branch be tracking the develop branches of the submodules? This way what your building/testing is more like what you plan on releasing. Changes in the develop branch correspond to changes that are intended for the *next *release (see the gitflow modelhttp://github.com/downloads/nvie/gitflow/Git-branching-model.pdf ). At some point in the development cycle of a release (e.g., release candidate time?), you create a release branch from develop in all the repositories and any last minute showstopper RC fixes go in them. Work can continue in the develop branches for the next, *next *release in parallel, i.e. no need to "freeze" the develop branch. Once every thing is building and passing in the release branches, the release branches can be (fast-forward?) merged into the master branches. Before deleting the release branches you'll want to rebase the RC changes onto develop so that any changes that occurred on the develop branch in parallel now look like they came after the RC changes. This will make it consistent with the eventual state of the master branch. Michael
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost