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

Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-06-04 02:39:29

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

Hi,

I would expect to have a branch for each release and hotfix instead of 
all the releases sharing the same branch. At work I'm used to have a 
main branch, one feature branche by feature and one release branch by 
release. This has the advantage of not needing the merge from develop to 
master and discovering that you can not merge because you depend on 
other parts that are not merged yet.

Which are the advantages of maintaining two parallel branches as develop 
and release? Why do we need to test two branches every time? I will 
expect that the main/trunk branch is tested every time and that each 
release branch is tested as soon as it is created and until it is released.

Developers needing to integrate their work could create an integration 
branch and why not they could request some testers to add this 
integration branch to be tested until it is merged to the main branch.

I recognize that this model could mean some more work for testers, but 
if with Git it is so simple to create branches and merge from them, I 
don't see why we should work with fixed branches.

Just my 2cts,
Vicente