> I'm +1 on this final summary. It infers that we are going to soon be adding a > job that runs CI checks on Master. This is good. That's probably a subject > for another thread. I do have one question about this approach. I think there > is probably a scenario where we need to fix an issue on the 4.x branch > itself. In this case I guess we would merge that commit back to master? And > then RM would have to keep track of when its safe to fast-forward to the > merged version of the fix?
My understanding is that we shouldn't ever have a reason to fix an issue directly on the 4.x branch itself. When 4.x is ready for a release, we will cut a new branch (e.g. 4.1.x) off of 4.x at that point. If we find we absolutely need a fix for 4.1.x, then ideally we should develop the fix on master then cherry-pick it into 4.1.x. I'm not sure we'd also cherry-pick it into 4.x since then 4.x would no longer be a snapshot of the most recent stable commit of master (meaning we wouldn't be able to just "fast-forward" -- in git terminology -- to the next most recent stable commit of master). IMO unless an absolutely necessary fix is also super time-sensitive, we should develop the fix on master and cherry-pick it into the 4.1.x branch. Then all cherry-picks would be tracked the same way, without also having to track hotfixes that need cherry-picked to master. Whenever cherry-picks/hotfixes are used, the important thing is just to make sure they get carried forward into the next release (either by bringing them in naturally via moving forward on master, or re-cherry-picking them). Again, these should only be things we deem absolutely necessary for a release (show-stoppers). - Rawlin
