[Scummvm-devel] Towards a new release branch model

[Max Horn]

Hi fuzzie!

First off, I appreciate your reply. let me note that I am happy to discuss other models, and to finally develop our own matching our needs. I just thought it's best to get the discussion started with a concrete suggestion ;). 

Another well-documented model is the one used by the git team itself:
<http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>
I like esp. the "merge upwards" part, in which the "release" branch is regularly merged back into the develop branch. (Yes, this causes merge conflicts if we change the version number in both branches -- but only once, after the first merge, this is not a problem anymore).

Although that git workflow in its pure form is probably a bit too radical for us (completely centered on feature branches, which we currently don't employ). Still, we hopefully can draw some inspiration from it. 

But back to your specific points.


Am 30.05.2011 um 15:27 schrieb A. Milburn:

> On Mon, May 30, 2011 at 02:38:20PM +0200, Max Horn wrote:
>> for "Release branches" and "Hotfix branches". 
> 
> It's not very clear to me what you want to change from the current model,
> if we're not going to insist on Feature branches. You're suggesting a
> stable branch which we merge release branches into?

Yes, but this is not the primary point, so reading it like that in isolation is a bit misleading :).

> Or that our development branch must only contain features which are intended for
> the next release?

Short answer: "Mu" <http://en.wikipedia.org/wiki/Mu_(negative)>

Long answer: This is orthogonal to / independent of what I had in mind. We currently put stuff in our development branch that are not necessarily meant for the next release; what we do is disable them in the release branch. We can certainly keep doing that.

That said, on the long run, switching to a feature-branch centered model promises to have many advantages, and I'd love if we switched to that. I am just afraid that it might be a bit too much for everybody right now.


> Or that we should merge all changes from release
> branches back into the develop branch rather than doing what we do
> now, which is applying fixes to the release branch and possibly
> 'better' but riskier fixes to the develop one? I am confused!

That's roughly it. The idea is that cherry picking is problematic on the long run and not "git like".

One example why it is problematic is that it is easy to "forget" to put changes made to the release branch also into master. This happened frequently in the past, esp. with changes for Maemo and Nintendo DS.

With the nvie as well as the gitworkflow models, the release branch is eventually merged into the stable branch, and the stable branch is merged into develo. So no commits are lost, and one automatically gets a "consistent" state, where no change from a release branch is ever "forgotten".
In gitworkflow(7) (the webpage / manpage), this corresponds to "master" (aka develop) always being a superset of maint (aka stable). In my perception, the main difference between the two models is when merges happens: For the nvie model, they only happen at select points; in the gitworkflow they happen more often (in particular, merges from release -> develop can happen during release hardening, which is IMHO useful for bugfixes that we want to have in both).


Now, the nvie model also suggests that the devel branch gets no concrete version assigned up until the release branch is made. That has some pros and cons. One pro is that if we don't call it 1.4.0git, then there is no trouble with users not wanting to use 1.3.0, because after all 1.4.0 is newer and hence "more shiny". And I think we avoid some of the "when to change the version" mess.
Another pro is that this avoids one source of potential merge conflicts: version number changes. But I am not sure if the cons (potential confusion about what version somebody is using) are worth it.
In fact, I'll go and find out how the fit folks really handle the version stuff upon merges.


In the meantime, I setup a test repository in which I used the "git-flow" tool and simulated a fake projects history, together with version number changes  similar to what we do / want (and including the ensuing conflicts, which I manually resolved when doing merges). 

Note that unlike the standard model, I did follow the "gitworkflow" in that I merged the release branch back into master *before* the final release, in order to make a bug fix on both. Anyway, see here for what I got (all the intermediate branches are gone in that, though):
<https://github.com/fingolfin/foobar/network>



Cheers,
Max