on Mon Jun 04 2012, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
On Mon, Jun 04, 2012 at 08:01:48AM -0400, Beman Dawes wrote:
The main development branch (i.e. what we currently call trunk) should probably also be easily discoverable by humans for uses like looking at development logs. Maybe also by automated processes, although I'm less sure of that. So its name should also be common to all boost projects. Seems like "master" is the traditional git name for this branch, but I'll defer to git experts on this one.
My reading of the document is that "master" is what Boost has traditionally called "release", and "develop" is what Boost has traditionally called "trunk".
Yes, that's git-flow terminology
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. 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 an individual maintainer will have a personal stake in all kinds of release activities, such as merging features from their integration branch ("develop") and writing release notes. Right now, since it's out of my hands when the world actually sees my changes, I am disincentivized from dealing with my release branch. -- Dave Abrahams BoostPro Computing http://www.boostpro.com