It is not uncommon to either cherry-pick a critical fix from master back into a release branch, or to make a packaging related change to fix language-specific packaging metadata and do it in the branch. All release branches should merge back into master even if they drop the version number changes.
I completed the effort yesterday. There were a couple minor things that had slipped through but no code changes in that area, just some metadata. If you look on GitHub now for branches, it'll show you that all our release branches are zero commits ahead of master. This means nobody can submit those crazy merges from 0.9.3 into master any more. :) On Wed, Jan 9, 2019 at 3:23 AM Jens Geyer <jensge...@hotmail.com> wrote: > Why are there code changes in the brznch in the first place? > > Sent from mobile device, please ignore spelling mistakes. > ________________________________ > Von: James E. King III > Gesendet: 08.01.2019 16:33 > An: dev@thrift.apache.org > Betreff: Branch history fixups > > 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 >
