Re: [boost] [git/modularization] Suggested names for branches?

Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Daryle Walker (darylew_at_[hidden])
Date: 2012-06-07 08:30:18

Date: Mon, 4 Jun 2012 22:47:50 -0500
From: Steve

>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".
> 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? 

The git-flow "master" branch contains canonical releases ONLY.  Ourcurrent "release" branch is in flux with changes until someone decidesto "ship it," and we make the ZIP (or whatever) files from that tagpoint.  The git-flow "master" branch only has those "ship it" points.If we have been using git-flow for Boost's lifetime, it would have only around 60changes, corresponding to our ~60 releases.
As you said, we would make our current "trunk" the new "develop" branch.At time of release, we create a temporary "release" branch, instead ofa semi-permanent one.  Once we clean up the "release", we copy the "shipit" changes to both the "master" and "develop" branches.  Then we killthe "release" branch.
Hot fixes work the same way as releases.  The difference is that "release"branches are split from "develop" while "hot-fix" is split from "master."After certification, the changes are imported to both permanent branchesand the temporary one is killed.
If you didn't know, "master" is the name of the default branch when youcreate a Git repository.  It's also the only branch from a remote sitewhen you copy/import/clone it, if there's no public branches added.Since the git-flow master branch is only for canonical releases, regularusers new to Boost will start off with production code!  A user thatwants to develop, or see the latest code, has to intentionally switchto the "develop" branch to see the latest code.  Whichever of the twopermanent branches s/he uses, s/he can make a hot patch for any problemsand send in a diff to our bug-tracker (or this list).
This "master == canonical" will help the Boost developers if we makesubrepositories per library.  Each library will use the "develop" and"master" system, along with any (private) feature branches.  Remember thatwe can use each other libraries.  The situation now is that we all shareeach other's beta code for our dependencies.  But I'm proposing that whenone Boost library depends on another, the library just points to thecanonical & stable version on the other's "master" branch!  At releasetime, the coordinator merges all the latest master versions to test themfor cross-compatibility (in the "release" branch).  After the adjustments,we create a new entry for the entire-Boost "master" and import any changesto each individual "master" branch (unless that library didn't change).
Daryle W.