[Scummvm-devel] Towards a new release branch model

Max Horn max at quendi.de
Wed Jun 1 17:12:24 CEST 2011


[ Many good points on this thread by multiple people. Just replying to a few of them. ]

Since it was correctly pointed out that one should explain why a new process improves things:

In my eyes, the major advantage of the whole "merge stable into master" is the following: We don't ever again "forget" fixes or improvements made only on the branch, as has happened so often in the past. And compared to manually cherry-picking changes made on stable back to master (mind you, we could be talking about some dozen commits made by porters to stable but not master) is that the history of the change is clear (i.e. the fact that it was first introduced on stable).

There are potentially disadvantages, too, see the other thread; but currently, my personal feeling is that these cons can be mostly resolved, or are far small than the pros. However, I am still not quite decided on what I prefer myself, so take that with a grain of salt.


Am 01.06.2011 um 00:05 schrieb Michael Madsen:

[...]
> 
> That is the difference between theory and practice. I fully agree that there *are* flaws with the current approach (even though I never experience them on account of not working with the source), but at the end of the day, a bunch of people have to follow this new workflow.

Actually, when it comes to merging stable to master, only a handful of people would need to worry about that. Not all 50 active team members. Probably just Eugene and me at the start. Of course, everybody else  would be asked to contribute by reviewing the merge before it's done in the future (unlike what I did this time, see the other thread for that).

Also, I see two alternative ways: We could perform only one big merge from stable to master at the end (as I just did). Or we perform multiples. Note that git is pretty clever about the cherry picks. They caused no conflicts for me (unlike with SVN in the past). So both approaches seem feasible to me, and have their pro and cons.


The alternative approach, with multiple merges, could work like this:

If during a release cycle, we discover a bug that needs to be fixed on "stable", then we do so. Next, we determine whether it needs to be fixed on master, too; and if the same fix can be used or not. Based on this information, Eugen/me/whoever (or the original bug fixer, if he knows how to) merges the stable branch into master. If the same fix is to be used on master, that's it. If a different fix is to be used, then the merge is immediately followed up by a "reverse cherry pick", as Marcus called it.
This also avoid the problem of accidentally merging a "hotfix" when master already contains a proper fix. Though that can also be detected if we only do one big merge in the end: Because we should review all changes made in a merge compared to master anyway, and each of these changes should  be reviewed by the team and approved, or flagged as inappropriate.

To avoid merge conflicts due to versions, I envision that right after the branch-off (in which the version is changed on both branches), we would merge stable back into master (resolving the conflicts due to the version difference, which would be trivial to do at that point). This way, this conflict wouldn't have to be resolved again later on (except maybe after the final change from "1.3.0pre" to "1.3.0").

When the MSVC files are added to stable, then this too could be followed by a merge which simply omits the new files (as I did with my recent stable->master merge). I am a bit torn on whether I like this or not. Having the merge commit in there might be a little confusing; then again, I can't think of an actual disadvantage caused by it (doesn't mean there is none, of course :-).


The key point here: For most devs, nothing would change. The person making the fix would not have to be the same as the one performing the merge. 



Cheers,
Max



More information about the Scummvm-devel mailing list