I merged all release branches into master with the ‘ours’ strategy, which means that future merges won’t include the release-specific changes such as versions and upstream branches. Now you can commit directly to the release branch if you have something to fix for the release, and those changes will be merged into master just before the release. The advantage of this approach is that no cherry-picking is necessary, which duplicates commits and is easy to forget.
We’ll use the same approach for the maintenance_2.11 branch after the release, and also for all following maintenance branches.
Miro
Hi,
the 2.11.0.RC1 milestone is published. We should use this one for testing the upcoming 2.11.0 release.
I propose the following approach for continuing work on Xtext:
* I’ll create “release_2.11.0” branches on all repositories, from which the release will be built in two weeks. All changes (important bugfixes) that should be included in the release need to be cherry-picked onto these branches.
* I’ll switch the “master” branches to 2.12.0-SNAPSHOT.
* When the release is done, I’ll create “maintenance_2.11” branches from which we can derive maintenance releases (2.11.1 etc.)
Cheers Miro
Hi all,
when scheduling the release review I overlooked a message on the top of the website asking me to additionally send a mail to the emo. I did that only today, but due to fixed release review dates the emo pushed the release date to February 1st. Sorry for that.
Regards, Sven
-- Dr. Miro Spönemann
Software engineer and consultant
Am Germaniahafen 1, 24143 Kiel
Tel.: +49 151 42679459
Sitz: Kiel, Registergericht: Amtsgericht Kiel, HRB 17385 Geschäftsführer: Sven Efftinge, Dr. Jan Köhnlein, Moritz Eysholdt
|