branchs and tags and merges oh my!

[servilio]

On 3 July 2011 08:44, David Bremner  wrote:
> On Sun, 3 Jul 2011 03:14:03 -0400, servilio  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

branchs and tags and merges oh my!

[servilio]

On 3 July 2011 08:32, David Bremner  wrote:
> On Sat, 2 Jul 2011 15:23:02 -0500, Jed Brown  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

branchs and tags and merges oh my!

[David Bremner]

On Sun, 3 Jul 2011 03:14:03 -0400, servilio  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


-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 

branchs and tags and merges oh my!

[David Bremner]

On Sat, 2 Jul 2011 15:23:02 -0500, Jed Brown  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.60.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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 

branchs and tags and merges oh my!

[servilio]

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

[servilio]

On 2 July 2011 13:30, David Bremner da...@tethera.net wrote:
 On Sat, 2 Jul 2011 11:59:04 -0400, servilio servi...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: branchs and tags and merges oh my!

[David Bremner]

On Sat, 2 Jul 2011 15:23:02 -0500, Jed Brown j...@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.60.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


pgpDUhNfniWub.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: branchs and tags and merges oh my!

[David Bremner]

On Sun, 3 Jul 2011 03:14:03 -0400, servilio servi...@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




pgpczui1DBjl0.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

branchs and tags and merges oh my!

[Jed Brown]

On Sat, Jul 2, 2011 at 07:44, David Bremner  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.

branchs and tags and merges oh my!

[David Bremner]

On Sat, 2 Jul 2011 11:59:04 -0400, servilio  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-pre0.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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 

branchs and tags and merges oh my!

[servilio]

On 1 July 2011 19:47, David Bremner  wrote:
> On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard  
> 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.6master
> ? ? ? ? ? ? \
> ? ? ? ? ? ? ?- 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.

branchs and tags and merges oh my!

[David Bremner]

On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner  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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 

branchs and tags and merges oh my!

[Tom Prince]

On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner  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!

[David Bremner]

On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner da...@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


pgpGQ4jg6rpr9.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: branchs and tags and merges oh my!

[Tom Prince]

On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner da...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: branchs and tags and merges oh my!

[servilio]

On 1 July 2011 19:47, David Bremner da...@tethera.net wrote:
 On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard kei...@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.6master
             \
              - 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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: branchs and tags and merges oh my!

[David Bremner]

On Sat, 2 Jul 2011 11:59:04 -0400, servilio servi...@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-pre0.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


pgpsFdga7Sh7r.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: branchs and tags and merges oh my!

[Jed Brown]

On Sat, Jul 2, 2011 at 07:44, David Bremner da...@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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

branchs and tags and merges oh my!

[David Bremner]

On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard  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.6master
 \
  - 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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 

branchs and tags and merges oh my!

[David Bremner]

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

branchs and tags and merges oh my!

[Keith Packard]

On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner  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 at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

branchs and tags and merges oh my!

[David Bremner]

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


pgpStOaTOFAi0.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch