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.
- Aidan
--
aim/y!:aidans42 g:[EMAIL PROTECTED] <[EMAIL PROTECTED]>
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to each
other."
