Branch Migration Strategy

These notes are only relevant to the branch migration done in February 2013.

These are my proposed branch migration steps for MonoGame. Our goals are:

1. To preserve all change history.
2. To limit the pain to downstream user forks.
3. To move all development from develop3d to develop.
4. To make master contain the state of the v3.0.0.0 release tag.
5. To eventually delete the develop3d branch.
6. Delete all the old unused branches.

We decided on a 'merge' base strategy instead of branch renames to honor #2.

NOTE: The following steps assume a new clean clone of MonoGame.

Notify Users

We should put up a news item on the MonoGame.net site as well as tweet about our branch migration. They need to know the following information:

• What changes are we making?
• Why we are making them?
• How does it affect them?
• How do they transition their forks?

We should do this immediately and give everyone at least a week to take notice and be aware.

Merge Develop3d Into Develop

We want to make develop our new mainline development branch. To do this the first step is merging develop3d into the develop branch. This means people downstream simply update and will get the latest development code from develop3d instead of the old 2.5 code currently in develop.

Whether they really want that or not is a separate question all together.

git checkout develop
git checkout develop3d
git merge -s ours develop 
git push origin develop3d
git checkout develop
git merge develop3d
git push origin develop

Note the push to develop3d which should help those when merging changes in their fork over to develop.

We can now leave the old develop3d around for a while. We will refuse all merges to it and give people a little time to transition to the new develop branch.

IMO we should delete develop3d a week or two after the migration... the longer it stays around more trouble it will be for us.

Merge 3.0 Into Master

We want to make master contain the latest stable release. To do this we need to merge the 3.0 release tag into master.

git checkout master
git checkout v3.0.0.0 -b master_v3.0.0.0
git merge -s ours master
git checkout master
git merge master_v3.0.0.0
git push origin master

Note the master_v3.0.0.0 branch is only a temporary local branch and is never pushed to upstream.

At this point master contains the content of the 3.0 release and downstream users will get it on the next update.

Delete Old Branches

The GitHub website now makes it easy to delete branches. We just need one of the core team members to go to the branches page and delete them. We should delete the following branches which all have not seen activity for a year:

• Rotation_Ipad2
• syderis
• flyingdevchanges

IMO we can do this right this second... but maybe letting users know first is better.

Transition Process For Downstream Users

TODO!