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
