On Mon, 2008-06-23 at 10:24 +0100, Aidan Skinner wrote:
> 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.
Yes but that's OK. The M{N}.x branch is always for work on the next
M{N}.x point release. As soon as that release is frozen & tagged the
branch belongs to the x+1 release.
> 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.
Don't do that. Never ever EVER merge from a less stable branch to a more
stable one. During the release cycle every fix needs to be evaluated as
to whether it's a fix that should go in the release or not. If it should
go in the release, do it on the release branch then merge to trunk. If
not, do it on trunk where it will never be merged to this release.
It means that people have to pay a bit more attention during the release
to where they base their work but that's not a bad thing.
> 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.
I don't think bi-directional merges are required, just some awareness of
the release process.
Note this scheme can be extended if we need critical fixes to a point
release, but we don't have to add those branches until we actually need
them, i.e. someone is screaming that they absolutely must have a fix to
M3.2, they cannot wait for the next 3.x point release, and we actually
care about their pain. At that point we create M3.2.x branch, which has
tags M3.2.1, M3.2.2
The same rules apply - merges always cascade from the most stable
branch to its parent and so on to the trunk.
>
> hack awesome shiny bugfix feature
> trunk ----*-------*-------^-------*-------^---------*---------*------^---->
> | | | |
> M3.x---*---------------*--------------------------^---->
> fix | critfix | ... | |
> M3.0 M3.0 M3.2 |
> RC1 FINAL | |
> M3.2.x
> -*----------------
> critfix
> |M3.2.1 ...
