branchs and tags and merges oh my!

servilio servilio at gmail.com
Sun Jul 3 00:14:03 PDT 2011


On 2 July 2011 13:30, David Bremner <david at tethera.net> wrote:
> On Sat, 2 Jul 2011 11:59:04 -0400, servilio <servilio at gmail.com> wrote:
>> What about having Carl do the merging of features into a develop
>> branch[1], then the release manager prepares a release in a release
>> branch, merging back and tagging into master when release is ready? A
>> similar workflow could be followed for bugfix releases (branch to
>> bugfix/release branch, prepare, merge back to master, tag).
>
> We could also call the develop branch "master" and use something like
> "release" for the branch that contains the release history.

I like this idea, two separate long-living branches for the releases
and development. What branch would be the head of the master
repository in this case? I'd prefer it to be "release", as it would
provide the latest stable release when cloning.

Also, in the name of the people that might want to build a stable
version from source, preparing the release in a separate branch might
be a good idea, merging the work there back to master when finished
and into release to make the release.

> This is is technically quite close to option #2, but perhaps conceptually
> clearer (and throwing in Tom's tagging idea).
>
>       0.7-pre          0.8-pre        0.9-pre
> -----.+--------------.+-------------.+------------- master
>      \             /              /
>       --------.    |             /
>                \  /     0.7     /
>                 +m------+-----+m--------+ release
>              0.6          0.7.1       0.8
>
> One difference in this version is that a merge from master onto release
> (and convenience tagging of master) occurs only when we are ready to release.

I think there is no need for tags on master, "make dist" should only
be run on the "release" branch, right?

Servilio


More information about the notmuch mailing list