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