Subject: Re: [boost] A proposal for superproject structure and testing
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-12 01:54:27
On Tue, Dec 10, 2013 at 4:06 AM, Rob Stewart <robertstewart_at_[hidden]>wrote:
> On Dec 9, 2013, at 6:42 PM, "Peter Dimov" <lists_at_[hidden]> wrote:
> > Cox, Michael wrote:
> >> Changes in the develop branch correspond to changes that are intended
> for the *next* release...
> > The develop submodule branch will eventually become the next *submodule*
> release. The master submodule branch is the current submodule release and
> will eventually be part of the next Boost release.
> >> 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.
> > That's very unlikely.
> I agree, and not just for Peter's reasons which I snipped. I think
> submodule testing should be against master of all (or most in special,
> coordinated evolution cases) other submodules. (This aligns with Robert
> Ramey's development and testing ideas.)
> It isn't sensible to test against unreleased commits to other submodules
> since the bleeding edge can have lots of churn.
It all depends on what the merge criteria from a feature branch to the
develop branch is. If the criteria includes running a release build and
unit-tests for the developer's compiler/platform then an automated
build/test across all platforms/compilers is likely to pass, providing
value information on the stability of the software earlier in the
development cycle. Also, if several libraries merge onto master near the
end of a boost development cycle, that sounds too much like big-bang
> The idealized process of creating a Boost release then means snagging the
> latest release commit from each submodule.
> I'm sure I've missed something, but that approach seems right.
> (Sent from my portable computation engine)
> Unsubscribe & other changes: