2008/6/20 Arnaud Simon <[EMAIL PROTECTED]>:
> 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
