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
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
>
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
Much to everyone's relief, 0.6 is finally released.
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
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
22 matches
Mail list logo
