Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-06-04 17:38:50
Le 04/06/12 18:26, Dave Abrahams a Ã©crit :
> on Mon Jun 04 2012, "Vicente J. Botet Escriba"<vicente.botet-AT-wanadoo.fr> wrote:
>> Le 04/06/12 03:18, Beman Dawes a Ã©crit :
>>> At the C++Now! session discussing moving to git and modularization, I
>>> showed the usual git flow overview graphic from
>>> http://nvie.com/posts/a-successful-git-branching-model/ showing the
>>> workflow for a library.
>>> Someone (Dave?) mentioned that the git flow choices for branch names
>>> were not what we would like for Boost. I agree, but don't recall the
>>> exact suggestions for more appropriate names.
>>> The three branches in question, with the git-flow names in parens,
>>> were the main development branch (develop), release prep branches (?),
>>> and the branch with actual releases (master).
>>> Is there a better usual convention for these names? I have a vague
>>> memory of someone mentioning "master" for the main development branch,
>>> "release" for the branch with the actual releases, and maybe
>>> "beta-x.xx.x" for release prep branches.
>>> To try to avoid an extended bicycle shed discussion, perhaps people
>>> could mention names they have actually seen used and know worked well.
>> I would expect to have a branch for each release and hotfix instead of
>> all the releases sharing the same branch.
> If you read the git-flow docs carefully, you'll see that they don't
> exactly share a branch in any trivial sense. The system is carefully
> organized to prevent out-of-control branch proliferation and encourage
> forward propagation of hotfixes.
I was responding to Beman post, which is proposing a specific work flow.
> I think you've misunderstood git-flow. There's nothing particularly
> "fixed" about the branches; they seem to work very similarly to what
> you're proposing.
Again, I don't know git-flow. I just read the link given in the OP.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk