branchs and tags and merges oh my!

branchs and tags and merges oh my!

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]


Much to everyone's relief, 0.6 is finally released.

From a git perspective, the release process went like this.

0) I branched release from master on June 22
1) I cherry-picked some subset of post June 22 commits from master to
   release 
1a) actually I cheated and cherry-picked the last few commits
    back from release to master. I don't _think_ this matters.
2) I tagged and uploaded from branch release

-----.-------------- master
     \
      ----------release 0.6

So now we have to decide what to do. FWIW, there are about 20 commits on
release past d6f05fd.

There are two obvious strategies going forward.

1) repeat the whole thing with a new release branch for 0.7 and end up
with

----------.--------------.------- master
           \              \   
            ----- 0.6      --- 0.7

2) merge master onto the release branch


-----------.--------.            ----- master
            \        \          /
             ---------.--------.---- 0.7
            0.6       now      freeze


I personally think having git log 0.6..0.7 do something sensible is
worth a lot, but this option does in some sense make the history of
master messier (some commits occur twice with different sha1's).


Discussion?

d

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: branchs and tags and merges oh my!

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner <david@tethera.net> wrote:

> 1) repeat the whole thing with a new release branch for 0.7 and end up
> with
> 
> ----------.--------------.------- master
>            \              \   
>             ----- 0.6      --- 0.7

That's the 'usual' plan followed by projects which use a central repository.

> 2) merge master onto the release branch
> 
> 
> -----------.--------.            ----- master
>             \        \          /
>              ---------.--------.---- 0.7
>             0.6       now      freeze

This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.

As an alternative, you probably should have simply put non-release
patches on a separate 'feature branch' (probably residing in the feature
author's repository) which would then be merged onto master post-0.6, in
the 'merge window' plan. That's the usual plan followed by projects
using multiple repositories and time-based releases. With this model,
you simply release from master when the time comes.

-- 
keith.packard@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: branchs and tags and merges oh my!

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard <keithp@keithp.com> wrote:
> > 2) merge master onto the release branch
> 
> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.

Can you elaborate? Naively it seems like one ends up with the same kind
of spur of history off of the 0.6 tag in both cases.

----.--------------master
    \
     ---- 0.6 ---- bugfix

versus

-----.----------.
      \          \ 
       ---- 0.6--------master
             \
              ----- bugfix

> As an alternative, you probably should have simply put non-release
> patches on a separate 'feature branch' (probably residing in the feature
> author's repository) which would then be merged onto master post-0.6

Yes, that is certainly nice from a git history point of view. On the
other hand the point of separating the roles of feature merger from
release mechanic was to allow Carl more time to work on merging features
into master, and I'm not sure how turning master over to the release
manager helps that.

David

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: branchs and tags and merges oh my!

[servilio]

On 1 July 2011 19:47, David Bremner <david@tethera.net> wrote:
> On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard <keithp@keithp.com> wrote:
>> > 2) merge master onto the release branch
>>
>> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.
>
> Can you elaborate? Naively it seems like one ends up with the same kind
> of spur of history off of the 0.6 tag in both cases.
>
> ----.--------------master
>    \
>     ---- 0.6 ---- bugfix
>
> versus
>
> -----.----------.
>      \          \
>       ---- 0.6--------master
>             \
>              ----- bugfix
>
>> As an alternative, you probably should have simply put non-release
>> patches on a separate 'feature branch' (probably residing in the feature
>> author's repository) which would then be merged onto master post-0.6
>
> Yes, that is certainly nice from a git history point of view. On the
> other hand the point of separating the roles of feature merger from
> release mechanic was to allow Carl more time to work on merging features
> into master, and I'm not sure how turning master over to the release
> manager helps that.

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

This workflow would keep a nice useful history while allowing even
more independence between the feature merging and release process,
what do you think?

Servilio

[1] Or next, or whatever other name is better understood by the community.

Re: branchs and tags and merges oh my!

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On Sat, 2 Jul 2011 11:59:04 -0400, servilio <servilio@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.  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.  If a bug fix release is desired, it can be done by
committing/cherry-picking on release.

d

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: branchs and tags and merges oh my!

[servilio]

On 2 July 2011 13:30, David Bremner <david@tethera.net> wrote:
> On Sat, 2 Jul 2011 11:59:04 -0400, servilio <servilio@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

Re: branchs and tags and merges oh my!

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Sun, 3 Jul 2011 03:14:03 -0400, servilio <servilio@gmail.com> wrote:
> 
> I think there is no need for tags on master, "make dist" should only
> be run on the "release" branch, right?
> 

It isn't just about make dist (which I anyway thinks makes sense to run
on master to make snapshots). Every compilation from git gets a version
number from running git-describe.  So unless we want all developers to
have useless/annoying version numbers, we have to care about tags on
master.

d



[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: branchs and tags and merges oh my!

[servilio]

On 3 July 2011 08:44, David Bremner <david@tethera.net> wrote:
> On Sun, 3 Jul 2011 03:14:03 -0400, servilio <servilio@gmail.com> wrote:
>>
>> I think there is no need for tags on master, "make dist" should only
>> be run on the "release" branch, right?
>
> It isn't just about make dist (which I anyway thinks makes sense to run
> on master to make snapshots). Every compilation from git gets a version
> number from running git-describe.  So unless we want all developers to
> have useless/annoying version numbers, we have to care about tags on
> master.

Why not just generate version when building from master in a different way?

Servilio

Re: branchs and tags and merges oh my!

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner <david@tethera.net> wrote:
> 
> So now we have to decide what to do. FWIW, there are about 20 commits on
> release past d6f05fd.
> 
> There are two obvious strategies going forward.
> 

A third strategy is "git checkout master && git merge -s ours 0.6". 
Then history will look like this:

  freeze       
--.-------------.----- master
   \           /
    -----------
               release

As long as every patch on the release branch is already on master, -s
ours (which throws away all the changes from the side branch) is
reasonable.

This has the advantage that "git describe master" starts to count from
0.6 instead of 0.5. Currently e.g. "make dist" on master is making
notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the
"increasingly innacurately named" effect, that is probably not what we
want.

d

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: branchs and tags and merges oh my!

[Tom Prince]

On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner <david@tethera.net> wrote:
> This has the advantage that "git describe master" starts to count from
> 0.6 instead of 0.5. Currently e.g. "make dist" on master is making
> notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the
> "increasingly innacurately named" effect, that is probably not what we
> want.

Another solution to this is to tag master just after branching with
something like 0.7-pre.

  Tom

Re: branchs and tags and merges oh my!

[Jed Brown]

On Sat, Jul 2, 2011 at 07:44, David Bremner <david@tethera.net> wrote:
>
> A third strategy is "git checkout master && git merge -s ours 0.6".
> Then history will look like this:
>
>  freeze
> --.-------------.----- master
>   \           /
>    -----------
>               release
>
> As long as every patch on the release branch is already on master, -s
> ours (which throws away all the changes from the side branch) is
> reasonable.

Remind me of why bugfix patches can't (usually) be applied to the
release branch first, then merged into master? When the patch is
(accidentally or otherwise) applied to master first, then I think you
have no choice but to have it appear twice in the history, once in
master and once in release, and using the model you describe above
seems the most sensible way to do that.

Re: branchs and tags and merges oh my!

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Sat, 2 Jul 2011 15:23:02 -0500, Jed Brown <jed@59A2.org> wrote:

> Remind me of why bugfix patches can't (usually) be applied to the
> release branch first, then merged into master?

Yes, that might work out for a "release" consisting of one or two
critical patches, and happening more or less instantly.  But maybe it
makes sense to make more of an effort to do (some of) the release
specific commits first on release and then merging to master, rather
than cherry-picking everything during a freeze.

In that case we obviously need to merge release back to master.  If we
want to have one long running release branch, this leads to cross
merging between the two branches.  

-----.--------------m------m-------.-- master
     |              ^      ^      /
      \            /      /______v                                                      
       \          /      /v
        .--------+------+m-------+
                0.6    0.6.1     0.7

This is all a bit hypothetical at this point of course, since there has
never been a bug-fix release.

d

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: branchs and tags and merges oh my!

[servilio]

On 3 July 2011 08:32, David Bremner <david@tethera.net> wrote:
> On Sat, 2 Jul 2011 15:23:02 -0500, Jed Brown <jed@59A2.org> wrote:
>
>> Remind me of why bugfix patches can't (usually) be applied to the
>> release branch first, then merged into master?
>
> Yes, that might work out for a "release" consisting of one or two
> critical patches, and happening more or less instantly.  But maybe it
> makes sense to make more of an effort to do (some of) the release
> specific commits first on release and then merging to master, rather
> than cherry-picking everything during a freeze.

If by "a freeze" you mean freezing Carl's working branch, I agree,
that work is better done in different branch so no restriction is
imposed on Carl workflow.

> In that case we obviously need to merge release back to master.  If we
> want to have one long running release branch, this leads to cross
> merging between the two branches.
>
> -----.--------------m------m-------.-- master
>     |              ^      ^      /
>      \            /      /______v
>       \          /      /v
>        .--------+------+m-------+
>                0.6    0.6.1     0.7
>
> This is all a bit hypothetical at this point of course, since there has
> never been a bug-fix release.

But there shouldn't be any issue, any changes done in "release" should
be merged back to master as I see it.

Servilio