whoops, my previous reply was to the wrong email thread (meant for the Release Process thread instead). I'll re-reply to the correct thread :)
- Rawlin On Mon, Nov 4, 2019 at 2:40 PM Rawlin Peters <[email protected]> wrote: > > > 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
