Rafael Schloming wrote:
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
+1 for stabilizing on the trunk instead of always needing to merge
stabilization changes.
-Ted
