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

Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-06-04 08:01:48

On Mon, Jun 4, 2012 at 2:39 AM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> 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.

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

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.

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

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

--Beman