Boost logo

Boost :

Subject: Re: [boost] Request for comments on super-project workflow doc
From: Peter A. Bigot (pab_at_[hidden])
Date: 2014-01-02 16:30:05

On 01/02/2014 02:58 PM, Peter Dimov wrote:
> Peter A. Bigot wrote:
>> * Branch "latest": automatically tracks "develop" of submodules
>> (scripted).
> ...
>> Does anybody have a use case for this?
> Yes.
> This branch is the equivalent of the old SVN trunk. It enables testing
> of the develop branches of the submodules. The typical Boost developer
> workflow is:
> - make changes
> - run local tests
> - when those pass, commit to develop (SVN trunk)
> - wait a few days for the develop (SVN trunk) testers to cycle
> - when those pass, merge to master (SVN release)
> In addition, testing a composition of the develop branches of the
> submodules enables people to detect inadvertent breaking changes in a
> dependent submodule and complain loudly. This ideally happens before
> the merge to master. (Or, alternatively, if the changes were in fact
> deliberate, it enables them to fix their code ahead of the merge to
> master.)

Ack. FWIW, that's not how I see submodule-based git projects in the
general case. If most Boost modules are independent (are they?), this
process appears to introduce unnecessary coupling, rather like testing a
bunch of unrelated feature branches together instead of validating and
merging them one at a time as their individual developers feel they're

I suspect that separate curated develop and auto-updated latest/master
(latest/develop) would be more robust. E.g. that approach reduces the
risk of refactoring the assert library: neither module would appear in
the stable branch (develop, in my proposal) until a release manager
confirms they're compatible, preventing the churn from impacting people
who don't care where the capability is placed.

But as long as everybody who maintains a Boost module is clear on the
expectations and process, the assumptions of non-Boost people aren't
particularly relevant.

>> Boost imposes no stability requirements on submodule develop
>> branches, let alone interoperability requirements.
> That's not - quite - true. The develop branches are expected to work,
> even though this is not strictly enforced. We mostly rely on the honor
> system. :-)

OK. Somebody should update
then, since no stability expectation is mentioned. In its current form,
I would expect to feel free to initiate a long-term refactoring on my
develop branch with no plans to push to master or maintain compatibility
with other modules for several super-project release cycles, a process
more consistent with my expectations of what the module master and
develop branches mean under git-flow.


Boost list run by bdawes at, gregod at, cpdaniel at, john at