+1 for the approach.
Regards,
Rajith
On Sun, Jun 22, 2008 at 7:33 PM, Martin Ritchie <[EMAIL PROTECTED]> wrote:
> 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
