[Scummvm-devel] Towards a new release branch model

[Miguel Bernabeu]

Hi all,

> I think you skipped over the most important point in fuzzie's questions:
> How do we handle bugs which get "quick fixes" on the release branch,
> and more thorough fixes on "trunk".  Do we immediately merge the quick
> fix and then revert it ("reverse cherry-picking") before making the
> thorough fix, or do we make the fixes in parallel and get a conflict
> when later merging the quick fix (or worse, _not_ getting a conflict
> and potentially have two fixes for the same thing)?

If I'm thinking straight, this is solved by usual rebase and merge. I
suppose a quick fix is done because there's no time for a good fix before
the release because if there was time enough the thorough fix would be used
instead.

We have our development branch ("master") and we prepare for a release
(simply stating our code is mature), so we branch "stable". A bug is found
in "stable", so we branch for bugfix or apply directly a bugfix (quick or
not). At the same time we are working in new stuff on "master" _but_not_
bugfixing "master". Now we rebase "stable" changes onto "master", so the
quick fix is applied to "master" and a thorough fix can be applied later,
without reverting the quick fix, simply a modifying commit.

When the time comes we tag our "stable" branch, rebase onto "master"
whatever wasn't rebased yet and continue working in "master".
Time for another release! Straight-forward merge from "master" to "stable",
"stable" branches out and repeat.

The most important part is to bugfix only in "stable" (except if the bug is
only present on "master"). This prevents cherry-picking, history is
consistent and most merges are straight-forward and clean.

My 2 cents,
Miguel

2011/5/31 Marcus Comstedt <marcus at mc.pp.se>

>
> Max Horn <max at quendi.de> writes:
>
> > Well, they do have releases every couple weeks or so. It's hard to
> imagine that they never find a bug in 1.x.y.z that ought to be fixed in
> 1.x.y.(z+1), right away, but for which a "proper" fix requires a
>  substantial change that is not desirable for that. But maybe that just
> never happens to them due to incredible luck / planning. Or do they simply
> refuse to fix urgent data loss bugs as long as no "proper" solution can be
> implemented, even if a hotfix is known?
>
> The tendency seems to be to refuse bugfixes unless they restructure
> the whole code according to Junio's visions of how the bug _should_ be
> fixed, yes.  The case I was involved with was a bug in ident handling
> which caused data loss.  Of course, Junio doesn't use ident, so it
> wasn't urgent to _him_...
>
>
>  // Marcus
>
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110531/19434422/attachment.html>