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

On Tue, Dec 10, 2013 at 4:06 AM, Rob Stewart wrote:

On Dec 9, 2013, at 6:42 PM, "Peter Dimov" 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.

[snip]

...

...

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

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.

___ Rob

(Sent from my portable computation engine)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost