qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Source management for releases
Date Thu, 19 Jun 2008 10:11:17 GMT
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 ----*------ *-------*-------*-------*---------*---------*----------->
                      |   |               |         |


|              |


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

- Aidan
aim/y!:aidans42 g:aidan.skinner@gmail.com <g%3Aaidan.skinner@gmail.com>
"We belong to nobody and nobody belongs to us. We don't even belong to each

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message