Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-10-23 22:26:52
on Wed Oct 23 2013, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
> Dave Abrahams wrote:
>> The release managers (or a continuous integration script) assembles a
>> release candidate that references, by default, the latest commits to the
>> "master" branch of all submodules. Test failures may result in rolling
>> back to earlier commits on that branch in a given submodule.
>> In other words, library authors release their code on whatever schedule
>> they like, and Boost release managers assemble a combination of library
>> releases into a Boost release.
> I'm a proponent of the use of Git and GitFlow in boost (in fact I
> *might* have been the first to suggest GitFlow ) as well as of
> modularization, but I can't help seeing a potential problem with this
> What do you do if module releases conflict? For example, if the
> latest release of module A is only compatible with older releases of
> module B, or if one module depends on the latest version of B while
> another depends on the previous? When such effects propagate you
> might have to be very conservative with the global update even though
> most modules have updated several times in the meanwhile.
One or more modules don't advance their version in the official Boost
distribution until one or both of the maintainers solve the problem.
> In my opinion it would be better to make hotfixes in the offending
> modules (using standard gitflow hotfix branches) so that every Boost
> release can include the latest versions of all modules.
> Of course, that requires more coordination between the release
> managers and the library maintainers.
Exactly. One of the main points of modularizing is to minimize the
coordination burdens associated with our processes. Especially when you
have an organization of volunteers, creating a situation where one
person's non-responsiveness can stymie overall progress is a bad idea.
-- Dave Abrahams
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk