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
