Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-06-09 17:33:56
on Sat Jun 09 2012, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
> On Tue, Jun 05, 2012 at 10:58:25AM -0400, Dave Abrahams wrote:
>> > The basic release workflow proposed sounds exactly like the current
>> > one: it's a promotion/integration model. As a consumer of Boost
>> > libraries, I've frequently found reported bugs "fixed" when they enter
>> > the development branch but it's very time consuming to ascertain
>> > whether a given bug fix ever made it into a release. Is there any
>> > thought how to address this in the new workflow?
>> Well, the difference here is that individual maintainers decide when/how
>> to release their own libraries.
> So are you saying that the Boost source control model will move from a
> monolithic promotion model to a a fine-grained promotion model? So
> each library maintainer is going to push changes from "devel" to
> "release" on their own?
> I thought that's what happens now, so I don't see the difference.
One difference is that the project's release branch is never closed.
You never need a release manager's permission to make a release.
> It's the promotion model itself that is, IMHO, broken. Or at least, I
> still haven't learned of a good way to handle issue tracking that
> includes both the state of "fixed in devel" and "fixed in release".
That is an important issue.
> The lack of this distinction is a source of frustration from my end.
> On the other hand, handling this distinction manually would create
> more procedure for maintainers fixing bugs. There must be an
> automated solution out there.
>> A "boost release" will only ever
>> contain some combination of released library versions, but individual
>> maintainers can announce and release a new version of their own
>> libraries at any time.
> So how is a boost release created? Are you saying that anytime a
> library maintainer makes a release, that a new release of Boost is
No. A release will be made by Boost release managers on a regular
> Or will boost be broken up into smaller modules with loose coupling
> between them so that they can release on independent cycles?
That too. A Boost release is a package consisting of a tested
combination of released versions of Boost libraries.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk