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 v3.0 release.
5. To eventually delete the develop3d branch.

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.

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 get the latest develop3d.

Weather they 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

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

Transition Process For Downstream Users

TODO!