You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Aidan Skinner <ai...@apache.org> on 2008/06/19 12:11:17 UTC
Source management for releases
Qpid Nation,
previously I don't think we've managed source, and particularly branch
management, very well. We've ended up with a proliferation of branches, no
clear documention of what should go where, how it gets between branches and
when a branch dies, which has lead to a few... unpleasent... merges.
In a going forward, proactive, open and transparent manner I suggest that we
never close trunk for commits of any sort, it's always open for tasty new
feature awesomeness.
When we're ready to start bug fixing / stabalising for release, we branch an
M{N}.x and use that as a testing target. Fixes would occur on trunk and be
merged down.
Once that's in a decent state, we branch an M{N}.{O} where critical fixes
from M{N}.x get merged to (once they've been comitted to trunk) and that's
what we tag for relase.
For M{N}.{O+1} we take another branch from M{N}.x a bit further along once
further fixes from trunk have been merged down.
A diagram may be helpful, * represents a commit, | a merge or branch
hack awesome fix shiny critfix bugfix feature
trunk ----*------ *-------*-------*-------*---------*---------*----------->
| | | |
M3.x----*-------------------------------*-------------------*------------------------------------------->
| |
M3.0-----------*--------------------------------------------------------------->
Obviously if trunk is majorly divergent from the branch then it won't be
quite as simple as that, but that's theory and i think it should be pretty
workable.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com <g%...@gmail.com>
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to each
other."
M3 , M4 etc Release schedule...: was Source management for releases
Posted by Carl Trieloff <cc...@redhat.com>.
I have to start the mail by saying I have not yet caught up on all the
mails on this
thread yet, but it looks like we have consensus so I am going to put my
foot into it...
1. We are going to go with time boxed releases moving forward.
2. Try track on a 2 month cycle (from comments from a few people I have
spoken
to) - debate this point if you want to.
3. As we will not be feature driven but rather time driven we will publish a
compatibility matrix for each release.
Suggested release schedule for 2008
M3: August 29th --- All feature merges in by Aug 8th
M4: Oct 31st --- All feature merges in by Oct 10th
M5: Dec 19th --- All feature merges in by Nov 28th
This gives as 3 weeks in each cycle to focus on bug fixing, testing
and general quality before each release.
We could do M3 sooner if we want to as we have been working on it
for a while. Anyone want to try for M3 sooner?
Comment please....
Carl.
Re: Source management for releases
Posted by Aidan Skinner <ai...@apache.org>.
On Fri, Jun 27, 2008 at 4:18 PM, Andrew Stitcher <as...@redhat.com> wrote:
> I've created a full history git mirror of _trunk_ and I could rsync that
> anywhere you like to save the time of creating this again.
I already have it, thanks though :) If you know of somewhere it can be
pushed to that will allow push over http that'd be awesome, I think
gitorious only allows cloning.
> I tried to use git svn to deal with the branch histories as well but I
> couldn't make it work.
I have one with all the branches, and most of the tags (it didn't like
our tags/foo/bar structure much) right.
> When I first created this it took about 5 hours (overnight) to pull the
> entire history.
yeah, it wasn't quick for me either, but is *totally* worth it.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
Re: Source management for releases
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2008-06-27 at 15:17 +0100, Aidan Skinner wrote:
> ...
> If I can find time
> this weekend I'm going to push a whole-history copy of qpid to
> gitorious so that it can be cloned by one and all.
I've created a full history git mirror of _trunk_ and I could rsync that
anywhere you like to save the time of creating this again.
I tried to use git svn to deal with the branch histories as well but I
couldn't make it work.
When I first created this it took about 5 hours (overnight) to pull the
entire history.
Andrew
Re: Source management for releases
Posted by Aidan Skinner <ai...@apache.org>.
On Thu, Jun 26, 2008 at 5:08 PM, Rafael Schloming <ra...@redhat.com> wrote:
[snippage]
> This model does close down trunk for radical new feature development when a
> release occurs, but I would hope that the need to do radical new feature
> development during a release is an exception, not the rule, and in that case
> I think it's reasonable for the feature development to be done on a branch.
> Certainly if no such feature development is happening it would be nice to
> avoid the additional merge overhead of branching *before* stabilizing.
I'm down with this, especially given the wonder that is git so people
can still hack on new features, put them up somewhere and track trunk
without it actually needing to go into a release. If I can find time
this weekend I'm going to push a whole-history copy of qpid to
gitorious so that it can be cloned by one and all.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://cwiki.apache.org/qpid
Re: Source management for releases
Posted by Ted Ross <tr...@redhat.com>.
Rafael Schloming wrote:
> Aidan Skinner wrote:
>> Qpid Nation,
>>
>> previously I don't think we've managed source, and particularly branch
>> management, very well. We've ended up with a proliferation of
>> branches, no
>> clear documention of what should go where, how it gets between
>> branches and
>> when a branch dies, which has lead to a few... unpleasent... merges.
>>
>> In a going forward, proactive, open and transparent manner I suggest
>> that we
>> never close trunk for commits of any sort, it's always open for tasty
>> new
>> feature awesomeness.
>>
>> When we're ready to start bug fixing / stabalising for release, we
>> branch an
>> M{N}.x and use that as a testing target. Fixes would occur on trunk
>> and be
>> merged down.
>>
>> Once that's in a decent state, we branch an M{N}.{O} where critical
>> fixes
>> from M{N}.x get merged to (once they've been comitted to trunk) and
>> that's
>> what we tag for relase.
>>
>> For M{N}.{O+1} we take another branch from M{N}.x a bit further along
>> once
>> further fixes from trunk have been merged down.
>>
>> A diagram may be helpful, * represents a commit, | a merge or branch
>>
>> hack awesome fix shiny critfix bugfix feature
>> trunk ----*------
>> *-------*-------*-------*---------*---------*----------->
>> | | | |
>>
>> M3.x----*-------------------------------*-------------------*------------------------------------------->
>>
>>
>> | |
>>
>> M3.0-----------*--------------------------------------------------------------->
>>
>>
>> Obviously if trunk is majorly divergent from the branch then it won't be
>> quite as simple as that, but that's theory and i think it should be
>> pretty
>> workable.
>
> Ok, sorry to chime in late, but here are my thoughts...
>
> I think in general branching tends to get messy more quickly and
> easily than people expect, and this is true even if you're someone
> like me who always expects branches to be messy.
>
> Given this I tend to favor a release model that avoids branching
> unless absolutely necessary. Something along the lines of every n
> months we do a release by stabilizing trunk to the point where it
> meets our release criteria, and then make a release branch at that
> particular snapshot of trunk.
>
> I would also say that when bugs are reported against a particular
> release, we should as a general rule fix them on trunk and encourage
> users to upgrade to the next release. I would say only on a case by
> case basis should we backport specific fixes to any release branch. I
> think this policy avoids unnecessary branching/merging, and also
> ensures that release branches are kept stable unless there is good
> reason to disturb them.
>
> This model does close down trunk for radical new feature development
> when a release occurs, but I would hope that the need to do radical
> new feature development during a release is an exception, not the
> rule, and in that case I think it's reasonable for the feature
> development to be done on a branch. Certainly if no such feature
> development is happening it would be nice to avoid the additional
> merge overhead of branching *before* stabilizing.
>
> --Rafael
>
+1 for stabilizing on the trunk instead of always needing to merge
stabilization changes.
-Ted
Re: Source management for releases
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2008-06-26 at 12:08 -0400, Rafael Schloming wrote:
> I think in general branching tends to get messy more quickly and easily
> than people expect, and this is true even if you're someone like me who
> always expects branches to be messy.
Amen brother.
> Given this I tend to favor a release model that avoids branching unless
> absolutely necessary. Something along the lines of every n months we do
> a release by stabilizing trunk to the point where it meets our release
> criteria, and then make a release branch at that particular snapshot of
> trunk.
I like this, let me elaborate. I'll use M3.0, M3.1 etc as examples
because M{X}.{Y} confuses me :)
Before every release we lock the trunk for release stabilization. When
we ship, we create an M3.0 tag from trunk. We proceed fixing bugs &
improving things till our next release period, at which point we lock
the trunk again & make an M3.1 tag.
Now somebody wants to do a major refactoring or new features for version
4.0. Before they start we tag the trunk M3.2-base. We continue with
fixes & new 4.0 features on trunk. If all goes well we don't have to do
a 3.2 release until we're ready to release 4.0. Lock the trunk, ship &
tag M4.0.
Note so far we have major & minor updates with 0 branches :)
The only time we _need_ to branch is if we want to do a 3.2 release
*after* the M3.2-base tag was created. That could be for 2 reasons:
- 4.0 takes too long, we decide to do a 3.2 release first.
- we decide to issue a 3.2 fix release for users of M3.1 that can't
upgrade to 4.0 immediately.
In either case we branch M3.x from M3.2-base. Changes for M3.2 are
merged to M3.x first, then to trunk OR back-ported (not merged) from
trunk. When we are ready to release M3.2 we do the same thing but this
time using M3.x as our "trunk" - we lock M3.x, stabilize and tag M3.2.
>>From now on any further M3.x releases are done on the 3.x branch, so
they are isolated from the trunk.
So except in the (hopefully) exceptional cases above, we *never need a
branch*.
> I would also say that when bugs are reported against a particular
> release, we should as a general rule fix them on trunk and encourage
> users to upgrade to the next release. I would say only on a case by case
> basis should we backport specific fixes to any release branch. I think
> this policy avoids unnecessary branching/merging, and also ensures that
> release branches are kept stable unless there is good reason to disturb
> them.
Agreed. If there is no next-major-version work on trunk we never need a
branch, everything goes on trunk and into the next point release. If we
have started next-major-version work (big refactorings etc.) then we
have to make a choice: we can continue on trunk and risk having to
back-port the changes if we do need another point release OR we can
start the 3.x branch and merge to trunk.
For small fixes in areas that have not diverged much between trunk & 3.x
I'd be inclined to put them on 3.x, with everything else on the trunk.
>
> This model does close down trunk for radical new feature development
> when a release occurs, but I would hope that the need to do radical new
> feature development during a release is an exception, not the rule, and
> in that case I think it's reasonable for the feature development to be
> done on a branch. Certainly if no such feature development is happening
> it would be nice to avoid the additional merge overhead of branching
> *before* stabilizing.
Agreed. If someone wants to start 4.0 work while a 3.n point release is
going on, they create a 4.0-future branch, do their new work on that and
merge out stabilization changes from trunk. When the 3.n release is
closed, we lay down the 3.n+1-base tag and merge 4.0-future into the
trunk. At that point we can delete the 4.0-future branch and continue on
trunk.
Re: Source management for releases
Posted by Rafael Schloming <ra...@redhat.com>.
Aidan Skinner wrote:
> Qpid Nation,
>
> previously I don't think we've managed source, and particularly branch
> management, very well. We've ended up with a proliferation of branches, no
> clear documention of what should go where, how it gets between branches and
> when a branch dies, which has lead to a few... unpleasent... merges.
>
> In a going forward, proactive, open and transparent manner I suggest that we
> never close trunk for commits of any sort, it's always open for tasty new
> feature awesomeness.
>
> When we're ready to start bug fixing / stabalising for release, we branch an
> M{N}.x and use that as a testing target. Fixes would occur on trunk and be
> merged down.
>
> Once that's in a decent state, we branch an M{N}.{O} where critical fixes
> from M{N}.x get merged to (once they've been comitted to trunk) and that's
> what we tag for relase.
>
> For M{N}.{O+1} we take another branch from M{N}.x a bit further along once
> further fixes from trunk have been merged down.
>
> A diagram may be helpful, * represents a commit, | a merge or branch
>
> hack awesome fix shiny critfix bugfix feature
> trunk ----*------ *-------*-------*-------*---------*---------*----------->
> | | | |
>
> M3.x----*-------------------------------*-------------------*------------------------------------------->
>
> | |
>
> M3.0-----------*--------------------------------------------------------------->
>
> Obviously if trunk is majorly divergent from the branch then it won't be
> quite as simple as that, but that's theory and i think it should be pretty
> workable.
Ok, sorry to chime in late, but here are my thoughts...
I think in general branching tends to get messy more quickly and easily
than people expect, and this is true even if you're someone like me who
always expects branches to be messy.
Given this I tend to favor a release model that avoids branching unless
absolutely necessary. Something along the lines of every n months we do
a release by stabilizing trunk to the point where it meets our release
criteria, and then make a release branch at that particular snapshot of
trunk.
I would also say that when bugs are reported against a particular
release, we should as a general rule fix them on trunk and encourage
users to upgrade to the next release. I would say only on a case by case
basis should we backport specific fixes to any release branch. I think
this policy avoids unnecessary branching/merging, and also ensures that
release branches are kept stable unless there is good reason to disturb
them.
This model does close down trunk for radical new feature development
when a release occurs, but I would hope that the need to do radical new
feature development during a release is an exception, not the rule, and
in that case I think it's reasonable for the feature development to be
done on a branch. Certainly if no such feature development is happening
it would be nice to avoid the additional merge overhead of branching
*before* stabilizing.
--Rafael
Re: Source management for releases
Posted by Rajith Attapattu <ra...@gmail.com>.
+1 for the approach.
Regards,
Rajith
On Sun, Jun 22, 2008 at 7:33 PM, Martin Ritchie <ri...@apache.org> wrote:
> 2008/6/20 Arnaud Simon <as...@redhat.com>:
> > Hi,
> > I am +1 with that approach.
> > Arnaud
> >
> > On Thu, 2008-06-19 at 10:35 -0400, Alan Conway wrote:
> >> On Thu, 2008-06-19 at 11:11 +0100, Aidan Skinner wrote:
> >> > Qpid Nation,
> >> >
> >> > previously I don't think we've managed source, and particularly branch
> >> > management, very well. We've ended up with a proliferation of
> branches, no
> >> > clear documention of what should go where, how it gets between
> branches and
> >> > when a branch dies, which has lead to a few... unpleasent... merges.
> >> >
> >> > In a going forward, proactive, open and transparent manner I suggest
> that we
> >> > never close trunk for commits of any sort, it's always open for tasty
> new
> >> > feature awesomeness.
> >>
> >> Agreed.
> >>
> >> > When we're ready to start bug fixing / stabalising for release, we
> branch an
> >> > M{N}.x and use that as a testing target. Fixes would occur on trunk
> and be
> >> > merged down.
> >>
> >> >From past experience, I suggest fixes occur on M{N}.x and merge to
> >> trunk. Since the trunk is always open, merging from trunk to a release
> >> branch risks picking up changes not intended for the release.
> >>
> >> Another way of putting it: always merge from more stable branches
> >> towards less stable branches, never the other way around.
> >>
> >> > Once that's in a decent state, we branch an M{N}.{O} where critical
> fixes
> >> > from M{N}.x get merged to (once they've been comitted to trunk) and
> that's
> >> > what we tag for relase.
> >> >
> >> > For M{N}.{O+1} we take another branch from M{N}.x a bit further along
> once
> >> > further fixes from trunk have been merged down.
> >>
> >> Again - never merge from trunk to a release branch. Work intended for
> >> the next M3 point release must be done on the M3.x branch first, then
> >> merged to trunk. A critical fix for M3.2 would be done on the M3.2
> >> branch, merged from there to M3.x and finally merged from M3.x to trunk.
> >>
> >> > A diagram may be helpful, * represents a commit, | a merge or branch
> >> >
> >> > hack awesome fix shiny critfix bugfix feature
> >> > trunk ----*------
> *-------*-------*-------*---------*---------*----------->
> >> > | | | |
> >> >
> >> >
> M3.x----*-------------------------------*-------------------*------------------------------------------->
> >> >
> >> > | |
> >> >
> >> >
> M3.0-----------*--------------------------------------------------------------->
> >> >
> >> > Obviously if trunk is majorly divergent from the branch then it won't
> be
> >> > quite as simple as that, but that's theory and i think it should be
> pretty
> >> > workable.
> >>
> >> It is I've used very similar schemes in the past. If my comments about
> >> merging don't make sense let me know and I'll clarify.
> >>
> >> Cheers,
> >> Alan.
>
> +1 good to see a strategy written down. He're hoping it makes it on to
> the wiki/forrest/web.. if it hasn't already :)
>
> --
> Martin Ritchie
Re: Source management for releases
Posted by Martin Ritchie <ri...@apache.org>.
2008/6/20 Arnaud Simon <as...@redhat.com>:
> Hi,
> I am +1 with that approach.
> Arnaud
>
> On Thu, 2008-06-19 at 10:35 -0400, Alan Conway wrote:
>> On Thu, 2008-06-19 at 11:11 +0100, Aidan Skinner wrote:
>> > Qpid Nation,
>> >
>> > previously I don't think we've managed source, and particularly branch
>> > management, very well. We've ended up with a proliferation of branches, no
>> > clear documention of what should go where, how it gets between branches and
>> > when a branch dies, which has lead to a few... unpleasent... merges.
>> >
>> > In a going forward, proactive, open and transparent manner I suggest that we
>> > never close trunk for commits of any sort, it's always open for tasty new
>> > feature awesomeness.
>>
>> Agreed.
>>
>> > When we're ready to start bug fixing / stabalising for release, we branch an
>> > M{N}.x and use that as a testing target. Fixes would occur on trunk and be
>> > merged down.
>>
>> >From past experience, I suggest fixes occur on M{N}.x and merge to
>> trunk. Since the trunk is always open, merging from trunk to a release
>> branch risks picking up changes not intended for the release.
>>
>> Another way of putting it: always merge from more stable branches
>> towards less stable branches, never the other way around.
>>
>> > Once that's in a decent state, we branch an M{N}.{O} where critical fixes
>> > from M{N}.x get merged to (once they've been comitted to trunk) and that's
>> > what we tag for relase.
>> >
>> > For M{N}.{O+1} we take another branch from M{N}.x a bit further along once
>> > further fixes from trunk have been merged down.
>>
>> Again - never merge from trunk to a release branch. Work intended for
>> the next M3 point release must be done on the M3.x branch first, then
>> merged to trunk. A critical fix for M3.2 would be done on the M3.2
>> branch, merged from there to M3.x and finally merged from M3.x to trunk.
>>
>> > A diagram may be helpful, * represents a commit, | a merge or branch
>> >
>> > hack awesome fix shiny critfix bugfix feature
>> > trunk ----*------ *-------*-------*-------*---------*---------*----------->
>> > | | | |
>> >
>> > M3.x----*-------------------------------*-------------------*------------------------------------------->
>> >
>> > | |
>> >
>> > M3.0-----------*--------------------------------------------------------------->
>> >
>> > Obviously if trunk is majorly divergent from the branch then it won't be
>> > quite as simple as that, but that's theory and i think it should be pretty
>> > workable.
>>
>> It is I've used very similar schemes in the past. If my comments about
>> merging don't make sense let me know and I'll clarify.
>>
>> Cheers,
>> Alan.
+1 good to see a strategy written down. He're hoping it makes it on to
the wiki/forrest/web.. if it hasn't already :)
--
Martin Ritchie
Re: Source management for releases
Posted by Arnaud Simon <as...@redhat.com>.
Hi,
I am +1 with that approach.
Arnaud
On Thu, 2008-06-19 at 10:35 -0400, Alan Conway wrote:
> On Thu, 2008-06-19 at 11:11 +0100, Aidan Skinner wrote:
> > Qpid Nation,
> >
> > previously I don't think we've managed source, and particularly branch
> > management, very well. We've ended up with a proliferation of branches, no
> > clear documention of what should go where, how it gets between branches and
> > when a branch dies, which has lead to a few... unpleasent... merges.
> >
> > In a going forward, proactive, open and transparent manner I suggest that we
> > never close trunk for commits of any sort, it's always open for tasty new
> > feature awesomeness.
>
> Agreed.
>
> > When we're ready to start bug fixing / stabalising for release, we branch an
> > M{N}.x and use that as a testing target. Fixes would occur on trunk and be
> > merged down.
>
> >From past experience, I suggest fixes occur on M{N}.x and merge to
> trunk. Since the trunk is always open, merging from trunk to a release
> branch risks picking up changes not intended for the release.
>
> Another way of putting it: always merge from more stable branches
> towards less stable branches, never the other way around.
>
> > Once that's in a decent state, we branch an M{N}.{O} where critical fixes
> > from M{N}.x get merged to (once they've been comitted to trunk) and that's
> > what we tag for relase.
> >
> > For M{N}.{O+1} we take another branch from M{N}.x a bit further along once
> > further fixes from trunk have been merged down.
>
> Again - never merge from trunk to a release branch. Work intended for
> the next M3 point release must be done on the M3.x branch first, then
> merged to trunk. A critical fix for M3.2 would be done on the M3.2
> branch, merged from there to M3.x and finally merged from M3.x to trunk.
>
> > A diagram may be helpful, * represents a commit, | a merge or branch
> >
> > hack awesome fix shiny critfix bugfix feature
> > trunk ----*------ *-------*-------*-------*---------*---------*----------->
> > | | | |
> >
> > M3.x----*-------------------------------*-------------------*------------------------------------------->
> >
> > | |
> >
> > M3.0-----------*--------------------------------------------------------------->
> >
> > Obviously if trunk is majorly divergent from the branch then it won't be
> > quite as simple as that, but that's theory and i think it should be pretty
> > workable.
>
> It is I've used very similar schemes in the past. If my comments about
> merging don't make sense let me know and I'll clarify.
>
> Cheers,
> Alan.
>
Re: Source management for releases
Posted by Martin Ritchie <ri...@apache.org>.
2008/6/23 Kalle Kärkkäinen <ka...@intstream.fi>:
> Hi,
>
> Aidan Skinner:
>>
>> hack awesome shiny bugfix feature
>> trunk
>> ----*-------*-------^-------*-------^---------*---------*----------->
>> | | |
>> M3.x---*---------------*------------------------------->
>> fix | critfix |
>> M3.0 M3.0
>> RC1 FINAL
>
> I'm entering a conversation I've only lurked over, but here goes..
>
> As surely everyone on the list has experienced before, this is a common
> battle between branches and 'the-way-forward'. A balancing act between
> maintenance and new features or even more so balancing a process so that it
> still allows development and does not stagnate to bug fixes.
>
> I'm sure you people have tackled this successully before so I'll be brief.
>
> We have the trunk that continuously goes forward, and from that we freeze
> branches that receive only bugfixes. This would mean that any given release
> (or release candidate) with designated feature set can be honed to
> perfection and the relevant fixes may be applied to the trunk.
>
> But it also allows the trunk to be moving forward with greater speed and
> (possibly) more demanding refactoring work. Of course, in this thinking,
> branches are a one way street, bidirectionality is unwanted as in my
> experience it leads into situations where it's really hard to say what
> patches have been applied to what branches.
>
> --
> Kalle.
>
I'm not sure if the bi-directional merging is really what we would do.
As Kalle says if trunk undergoes major refactoring (as has just occur
ed in the java broker) then merging changes from trunk to any MX.x
branch isn't going to be possible. Hence a new M(X+1).x branch would
be required for releasing those changes. I would say that if a new
trunk feature was required/desired on an existing MX.x branch then
that feature would need to be 'ported' rather than merged. I would say
the same is true for bug fixes, if a bug fix on trunk is done then if
the test also highlights the problem exists on a MX.x branch then the
patch may not merge over due to refactoring etc. but the JIRA system
should be able to record the bug and the fixed locations.
Sure it means that a svn log is not going to tell you what code has
been ported but ideally commit logs would have sensible text along
with JIRA IDs which would allow the correlation.
I think the revised approach with tagging at release point will work
otherwise we may end up with a lot of branches needing love. Having a
single MX.x branch per major release means that we are not thinking
that we will provide patches on all previous releases only the major
MX releases.
I don't think our users would need or even want to have patching to
the level of MX.Y(with Patch a) up to MX.(Y+n) (with Patch a). We then
get in to issues of what we call that. MX.Y.Z? That would work if we
always apply all patches to all branches but if we skip one for some
reason then I'd say it all gets pretty muddy pretty quickly.
Hope that makes some sense.. my brain may not have spun up to speed
after a relaxing week off.
Cheers
Martin
--
Martin Ritchie
Re: Source management for releases
Posted by Kalle Kärkkäinen <ka...@intstream.fi>.
Hi,
Aidan Skinner:
> hack awesome shiny bugfix feature
> trunk ----*-------*-------^-------*-------^---------*---------*----------->
> | | |
> M3.x---*---------------*------------------------------->
> fix | critfix |
> M3.0 M3.0
> RC1 FINAL
I'm entering a conversation I've only lurked over, but here goes..
As surely everyone on the list has experienced before, this is a common
battle between branches and 'the-way-forward'. A balancing act between
maintenance and new features or even more so balancing a process so that
it still allows development and does not stagnate to bug fixes.
I'm sure you people have tackled this successully before so I'll be brief.
We have the trunk that continuously goes forward, and from that we
freeze branches that receive only bugfixes. This would mean that any
given release (or release candidate) with designated feature set can be
honed to perfection and the relevant fixes may be applied to the trunk.
But it also allows the trunk to be moving forward with greater speed and
(possibly) more demanding refactoring work. Of course, in this thinking,
branches are a one way street, bidirectionality is unwanted as in my
experience it leads into situations where it's really hard to say what
patches have been applied to what branches.
--
Kalle.
Re: Source management for releases
Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Jun 23, 2008 at 10:20 PM, Alan Conway <ac...@redhat.com> wrote:
> On Mon, 2008-06-23 at 10:24 +0100, Aidan Skinner wrote:
> > That probably
> > implies that non-critical bug fixes during the freeze for M{N}.x are applied
> > to trunk and then merged down after the freeze, which is a little odd since
> > merges can then happen in either direction, depending on what state the
> > branch is deemed to be in when the fix is made.
>
> Don't do that. Never ever EVER merge from a less stable branch to a more
> stable one. During the release cycle every fix needs to be evaluated as
> to whether it's a fix that should go in the release or not. If it should
> go in the release, do it on the release branch then merge to trunk. If
> not, do it on trunk where it will never be merged to this release.
What do we do in the case where it's not necessary for M{N}.x, but is
desireable for both trunk and for M{N}.x+1?
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: Source management for releases
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2008-06-23 at 10:24 +0100, Aidan Skinner wrote:
> A couple of revisions have been suggested, namely that we're quite bad at
> merging changes and having a lot of branches makes this worse.
> To reduce
> that need, we could drop the release branch and just tag RC's off M{N}.x, so
> it would look like:
>
> A diagram may be helpful, * represents a commit, | a merge branch or tag and
> a ^ the end point of a merge
>
> hack awesome shiny bugfix feature
> trunk ----*-------*-------^-------*-------^---------*---------*----------->
> | | |
> M3.x---*---------------*------------------------------->
> fix | critfix |
> M3.0 M3.0
> RC1 FINAL
>
> This approach would mean the release branch would be tagged for RCs, so
> would go from slush to frozen to slushy again for M{N}.x+1.
Yes but that's OK. The M{N}.x branch is always for work on the next
M{N}.x point release. As soon as that release is frozen & tagged the
branch belongs to the x+1 release.
> That probably
> implies that non-critical bug fixes during the freeze for M{N}.x are applied
> to trunk and then merged down after the freeze, which is a little odd since
> merges can then happen in either direction, depending on what state the
> branch is deemed to be in when the fix is made.
Don't do that. Never ever EVER merge from a less stable branch to a more
stable one. During the release cycle every fix needs to be evaluated as
to whether it's a fix that should go in the release or not. If it should
go in the release, do it on the release branch then merge to trunk. If
not, do it on trunk where it will never be merged to this release.
It means that people have to pay a bit more attention during the release
to where they base their work but that's not a bad thing.
> I'm kind of +0 on this, I think I prefer it despite the bi-directional
> merges but I'm worried that that may actually make the problem it's trying
> to address (missed merges) worse, not better.
I don't think bi-directional merges are required, just some awareness of
the release process.
Note this scheme can be extended if we need critical fixes to a point
release, but we don't have to add those branches until we actually need
them, i.e. someone is screaming that they absolutely must have a fix to
M3.2, they cannot wait for the next 3.x point release, and we actually
care about their pain. At that point we create M3.2.x branch, which has
tags M3.2.1, M3.2.2
The same rules apply - merges always cascade from the most stable
branch to its parent and so on to the trunk.
>
> hack awesome shiny bugfix feature
> trunk ----*-------*-------^-------*-------^---------*---------*------^---->
> | | | |
> M3.x---*---------------*--------------------------^---->
> fix | critfix | ... | |
> M3.0 M3.0 M3.2 |
> RC1 FINAL | |
> M3.2.x -*----------------
> critfix |M3.2.1 ...
Re: Source management for releases
Posted by Aidan Skinner <ai...@apache.org>.
A couple of revisions have been suggested, namely that we're quite bad at
merging changes and having a lot of branches makes this worse. To reduce
that need, we could drop the release branch and just tag RC's off M{N}.x, so
it would look like:
A diagram may be helpful, * represents a commit, | a merge branch or tag and
a ^ the end point of a merge
hack awesome shiny bugfix feature
trunk ----*-------*-------^-------*-------^---------*---------*----------->
| | |
M3.x---*---------------*------------------------------->
fix | critfix |
M3.0 M3.0
RC1 FINAL
This approach would mean the release branch would be tagged for RCs, so
would go from slush to frozen to slushy again for M{N}.x+1. That probably
implies that non-critical bug fixes during the freeze for M{N}.x are applied
to trunk and then merged down after the freeze, which is a little odd since
merges can then happen in either direction, depending on what state the
branch is deemed to be in when the fix is made.
I'm kind of +0 on this, I think I prefer it despite the bi-directional
merges but I'm worried that that may actually make the problem it's trying
to address (missed merges) worse, not better.
Thoughts?
- Aidan
Re: Source management for releases
Posted by Marnie McCormack <ma...@googlemail.com>.
I agree with what Aidan suggested, with Alan's amendments (thanks to both).
I think this is a good start, and working on trunk I'm all in favour of !
Looking forward to some trunk-ing next week.
Bfn,
Marnie
On 6/19/08, Aidan Skinner <ai...@apache.org> wrote:
>
> On Thu, Jun 19, 2008 at 3:35 PM, Alan Conway <ac...@redhat.com> wrote:
>
> > On Thu, 2008-06-19 at 11:11 +0100, Aidan Skinner wrote:
>
> >> When we're ready to start bug fixing / stabalising for release, we
> branch an
> >> M{N}.x and use that as a testing target. Fixes would occur on trunk and
> be
> >> merged down.
> >
> > >From past experience, I suggest fixes occur on M{N}.x and merge to
> > trunk. Since the trunk is always open, merging from trunk to a release
> > branch risks picking up changes not intended for the release.
> >
> > Another way of putting it: always merge from more stable branches
> > towards less stable branches, never the other way around.
>
> That does make more sense, lets do that. :)
>
> - Aidan
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com <g%...@gmail.com>
> http://aidan.skinner.me.uk/
> "We belong to nobody and nobody belongs to us. We don't even belong to
> each other."
>
Re: Source management for releases
Posted by Aidan Skinner <ai...@apache.org>.
On Thu, Jun 19, 2008 at 3:35 PM, Alan Conway <ac...@redhat.com> wrote:
> On Thu, 2008-06-19 at 11:11 +0100, Aidan Skinner wrote:
>> When we're ready to start bug fixing / stabalising for release, we branch an
>> M{N}.x and use that as a testing target. Fixes would occur on trunk and be
>> merged down.
>
> >From past experience, I suggest fixes occur on M{N}.x and merge to
> trunk. Since the trunk is always open, merging from trunk to a release
> branch risks picking up changes not intended for the release.
>
> Another way of putting it: always merge from more stable branches
> towards less stable branches, never the other way around.
That does make more sense, lets do that. :)
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."
Re: Source management for releases
Posted by Alan Conway <ac...@redhat.com>.
On Thu, 2008-06-19 at 11:11 +0100, Aidan Skinner wrote:
> Qpid Nation,
>
> previously I don't think we've managed source, and particularly branch
> management, very well. We've ended up with a proliferation of branches, no
> clear documention of what should go where, how it gets between branches and
> when a branch dies, which has lead to a few... unpleasent... merges.
>
> In a going forward, proactive, open and transparent manner I suggest that we
> never close trunk for commits of any sort, it's always open for tasty new
> feature awesomeness.
Agreed.
> When we're ready to start bug fixing / stabalising for release, we branch an
> M{N}.x and use that as a testing target. Fixes would occur on trunk and be
> merged down.
>>From past experience, I suggest fixes occur on M{N}.x and merge to
trunk. Since the trunk is always open, merging from trunk to a release
branch risks picking up changes not intended for the release.
Another way of putting it: always merge from more stable branches
towards less stable branches, never the other way around.
> Once that's in a decent state, we branch an M{N}.{O} where critical fixes
> from M{N}.x get merged to (once they've been comitted to trunk) and that's
> what we tag for relase.
>
> For M{N}.{O+1} we take another branch from M{N}.x a bit further along once
> further fixes from trunk have been merged down.
Again - never merge from trunk to a release branch. Work intended for
the next M3 point release must be done on the M3.x branch first, then
merged to trunk. A critical fix for M3.2 would be done on the M3.2
branch, merged from there to M3.x and finally merged from M3.x to trunk.
> A diagram may be helpful, * represents a commit, | a merge or branch
>
> hack awesome fix shiny critfix bugfix feature
> trunk ----*------ *-------*-------*-------*---------*---------*----------->
> | | | |
>
> M3.x----*-------------------------------*-------------------*------------------------------------------->
>
> | |
>
> M3.0-----------*--------------------------------------------------------------->
>
> Obviously if trunk is majorly divergent from the branch then it won't be
> quite as simple as that, but that's theory and i think it should be pretty
> workable.
It is I've used very similar schemes in the past. If my comments about
merging don't make sense let me know and I'll clarify.
Cheers,
Alan.