Re: [boost] A proposal for superproject structure and testing

Subject: Re: [boost] A proposal for superproject structure and testing
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-09 18:07:46

On Mon, Dec 9, 2013 at 5:16 AM, Peter Dimov <lists_at_[hidden]> wrote:

> 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
model<http://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
>