Heya Ildar, 1) The person responsible for the merge is whoever made the branch... so the release manager. It's probably going to be more of a team effort this time though, because the changes are not just tweaks to licenses and so on, they're fixes for critical bugs. 2) A release branch should get made every time we make a release so changes that are specific to the release itself can be done without holding up new features coming on to master. 3) That's not something that should be done ;) If something belongs on the release branch, it should really go there first. Cherry picking won't work because it rewrites the commit. You'll end up having 2 copies of a commit that are semantically equivalent but not equivalent int git's eyes.
-Ian On Wed, Nov 18, 2015 at 5:36 PM, Ildar Absalyamov <[email protected]> wrote: > Hi All, > > The concept of release branches introduced to unfreeze master while release > process is happening seems to have several issues, which are not clear for me. > Both me and Yingyi have similar changes, but his are committed to master, > whereas mine will go to release-0.8.8. > Those conflicts would be reconciled when the release branch is merged back to > master, however this leads to several questions: > 1. In general case who will be responsible for that merge? > 2. How do we generally decide when to make a release branch? > 3. Suppose the release branch was created at point ABC and possibly bug > fixes\features were submitted to it, but not to master. How would we handle > situation when some time later we decide that feature XYZ from master should > also be a part of release. Merge master into release branch (merging also > whatever happened in between ABC and XYZ)? Cherry-pick specific commit from > master? > > Best regards, > Ildar >
