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 made? Or will boost be broken up into smaller modules with loose coupling between them so that they can release on independent cycles? Thanks, -Steve