Boost logo

Boost :

Subject: Re: [boost] A proposal for superproject structure and testing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-09 07:32:24


On Monday 09 December 2013 14:16:33 Peter Dimov 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.)

I'd name latest as bleeding-edge, but that's not important.

> Test runners test all three, in sequence.

Am I correct that all develop branches will be tested together, not library
X/develop + everything else/master? I'm ok with that, just wanted to make
sure.

> 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.

Looks ok to me. In case if there is a hotfix from some library, is it possible
to create a pull request for a particular commit to the library master? Or
should it be addressed in this list?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk