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.
