Our release branching strategy has left a number of loose ends. Specifically, none of the release branches except for 0.12.0 have been merged back into master. Based on the way past releases were done, we would branch off master then make a number of versioning changes which were never intended to be merged back. Without merging back, this leaves the possibility that one could strand an important code change in a release branch. It also leaves master with incomplete history. In this type of merge one does a "git merge --strategy-option=ours origin/<branch>" and drops any collisions against master.
I'm going to start doing this for our release branches, ensuring the resulting differences are negligible. This will ensure we haven't missed anything along the way, and GibHub will understand that a merge has already occurred, so when we get a random pull request to merge 0.9.3 into master (seems to happen about twice a year), there will be nothing to do. - Jim
