Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Steve M. Robbins (steve_at_[hidden])
Date: 2012-06-09 14:06:18
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.
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".
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
Or will boost be broken up into smaller modules with loose coupling
between them so that they can release on independent cycles?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk