[Scummvm-devel] Towards a new release branch model

[Tarek Soliman]

On Mon, May 30, 2011 at 11:31:10PM +0200, Marcus Comstedt wrote:
> 
> Hi Max,
> 
> 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)?
> 
> Btw, if everything from release branches get merged back, then you
> can't put "releasification" things on release branches (for example
> disabling of serial port output in the DC port), so such things need
> to be controlled by --enable-release instead.  I seem to recall there
> were some problems with using this flag for additional things, but
> maybe that's been fixed with the restructuring of the configure
> script?

According to http://nvie.com/posts/a-successful-git-branching-model/:

At a basic level there are 3 branches.

There is a release branch where every commit is a release. That branch is a sink.
There is a develop branch where it is like the current master.
There is a hotfix branch (for putting in the quick fixes that cannot wait for the next release)

The release branch shouldn't be merged back to anything.
The hotfix branch does get merged back to release of course for the hotfix. It can also be merged back to develop.

If it is decided to be merged back to develop and there exists a better fix there, a conflict may happen and be resolved.
If the fix isn't there yet then if/when it happens it will replace the first fix (hopefully in the same commit)
Either way no explicit revert commit is needed.

Changes that are specific to releases would happen on a hotfix branch


Note that this workflow is different from the one that git uses.
The one git uses doesn't work for "release specific commits" since everything is merged back into the development branch and would have to be handled by configure options or something like that.
-- 
Tarek