On 01/02/2014 10:19 AM, Beman Dawes wrote:
The release managers with help from Peter Dimov have been developing super-project workflow documentation.
See https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow
Comments welcome!
A couple comments from an outsider who's done a lot of git and release process management, but is not deeply familiar with Boost history: For branch semantics: https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow#Namingrationale has: * Branch "latest": automatically tracks "develop" of submodules (scripted). I don't see a need for a branch with this tracking policy. Boost imposes no stability requirements on submodule develop branches, let alone interoperability requirements. The timeline for module development may not be targeting the next super-project release (e.g., Boost.Test has four years of changes in develop that have never seen a release). Further, any remaining material in the super-project that depends on submodule content (e.g. testing) may break badly, making the branch unusable. Does anybody have a use case for this? * Branch "develop": automatically tracks "master" of submodules (scripted). git-flow expects develop to be used to branch releases, but an automatic update policy makes it difficult to first reach a stable point with a curated set of submodule releases. It also makes it hard to submit patches to any non-module content in the superproject (and I believe there will always be some such, if nothing more than metadata and generic documentation). To address these issues I propose the following changes: * Branch "latest": Merges from super-project "develop" and tracks "master" of submodules (scripted). By this I mean the script does a merge from develop to pick-up non-submodule changes, followed by blind updating all submodules to their latest release (even if the merge from develop restored an older commit). While there will still be a risk of module interoperability problems, this branch should generally work. Its this material (and not submodule develop branches) that is proposed (but not yet accepted) to be part of the next release, so it's where automated integration testing should be done. * Branch "develop": Maintained by release managers, who merge periodically from "latest" at commits that pass integration testing, and from feature branches that change non-submodule content. This branch should be expected to be nearly-releasable at all times, since it references submodule releases that are known to interoperate and pass tests. It's the best choice for module maintainers to branch from so they can detect interoperability problems with dependent modules before updating their own master branches. For release preparation: https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow#Releasepreparatio... specifies that a release branches from master, which is not how git-flow works: releases branch from develop, and merge to master. This becomes possible with the develop semantics I'm proposing, where develop is curated rather than scripted. Also the comment about "branching for release early" seems inconsistent with git-flow's description that release branches are for last-minute cleanup and metadata updates. I've found that, if you branch too early, you waste time shuttling patches between the release branch and the develop branch. Branching when you're pretty sure you have a releasable system reduces rework. Peter