Subject: Re: [boost] Request for comments on super-project workflow doc
From: Peter A. Bigot (pab_at_[hidden])
Date: 2014-01-02 13:16:23
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:
* 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
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
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk