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

Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-06-04 12:31:42

Beman Dawes wrote
> 
> On Mon, Jun 4, 2012 at 2:39 AM, Vicente J. Botet Escriba
> <vicente.botet@> wrote:
>> I would expect to have a branch for each release
> 
> I think the issue is discover-ability. In a modularized Boost, each
> library will have its own repo and release cycle. So the question
> becomes what is the current release for this library?
> 
> If the current release is simply the head of the "release" branch,
> that's easy to answer both for humans and for automated processes.
> 

If we decide to have only one release branch, the head of this release
branch will not be IMO the last public release.
I guess that this information belongs IMHO to documentation and tools must
be configured to take the release that is needed. Taking the last release is
not something that always works on modularized repo. 
Using a single branch will not avoid the integrator of the whole Boost to
know about the tag that corresponds to the last public release of each
library, isn't it?

>> 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.
> 
> Hotfix and feature branches are local project workflow decisions, so
> their existence and names are up to that library's maintainer.
> 

What prevent us to have hotfixes for the whole Boost?
Feature/Integration branches could be shared between several library
authors.

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

I agree with this main/trunk/master branch.

>> Which are the advantages of maintaining two parallel branches as develop
>> and
>> release? Why do we need to test two branches every time?
> 
> The public repo needs a release branch at the minimum. For a really
> tiny library, I suppose a maintainer might do all work locally on that
> branch and then push to the public repo. But that would be poor
> development practice for real-world libraries.
> 

This is my concern. We need a trunk branch and more than a release branch
which are created from trunk at the moment the release contents is there. 

>> 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.
> 
> There are two cases; monolithic testing like we do now, and a future
> continuous integration test environment.
> 
> Monolithic testing would presumably still be based on trunk (under a
> new name) and release branches.
> 
> Continuous integration testing will be a different animal and we don't
> know the full details yet. But the development branch / release branch
> / various other ad hoc branches model is in use with numerous CI
> schemes for other projects, so is known to work in those environments.
> 
> 

I know and I work with CI systems and we use several release branches
without problems. I'm just saying that we need specific release branches and
not only one that forces merge from trunk for each release as we are doing
now.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/git-modularization-Suggested-names-for-branches-tp4630871p4630896.html
Sent from the Boost - Dev mailing list archive at Nabble.com.