qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Re: Source management for releases
Date Mon, 23 Jun 2008 09:24:55 GMT
A couple of revisions have been suggested, namely that we're quite bad at
merging changes and having a lot of branches makes this worse. To reduce
that need, we could drop the release branch and just tag RC's off M{N}.x, so
it would look like:

A diagram may be helpful, * represents a commit, | a merge branch or tag and
a ^ the end point of a merge

         hack  awesome         shiny             bugfix   feature
trunk ----*-------*-------^-------*-------^---------*---------*----------->
                      |   |               |
                   M3.x---*---------------*------------------------------->
                         fix     |      critfix        |
                              M3.0                   M3.0
                               RC1                   FINAL

This approach would mean the release branch would be tagged for RCs, so
would go from slush to frozen to slushy again for M{N}.x+1. That probably
implies that non-critical bug fixes during the freeze for M{N}.x are applied
to trunk and then merged down after the freeze, which is a little odd since
merges can then happen in either direction, depending on what state the
branch is deemed to be in when the fix is made.

I'm kind of +0 on this, I think I prefer it despite the bi-directional
merges but I'm worried that that may actually make the problem it's trying
to address (missed merges) worse, not better.

Thoughts?

- Aidan

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