I have also used the pattern of releasing from a release branch and cherry-picking (as opposed to merge) fixes from main to the release branch as needed for the release (on commercial software products), and it worked well.
As long as you have a regular and frequent release schedule (as Arrow does with quarterly releases), most cherry-picks are likely to happen very soon after the release branch is cut, when the divergence from main is the smallest, and thus the chance of conflicts remains low. On Thu, Nov 26, 2020 at 3:07 AM Antoine Pitrou <anto...@python.org> wrote: > > Personally, I simply don't really understand the aversion for merge > commits. The need to recreate the "master" branch locally after a > release has bitten me several times (git lets you screw that up very > easily...), and it has always been a bit frustrating. > > Regards > > Antoine. > > > Le 26/11/2020 à 02:02, Jacques Nadeau a écrit : > >> > >> I don’t have a problem with releasing out of branches. I think I (or > >> someone) proposed this in the past and there was not consensus but it > seems > >> like a good time to revisit the issue. > >> > > > > Thanks for the recap. I just couldn't remember where people were at on > this. > > > > I'm a big +1 for releasing out of branches. The biggest downside from my > > pov is that if the release takes a long time, you spend some time > > cherry-picking. That being said, I think the other pros (development > isn't > > stalled, you don't have force pushes, etc) outweigh the cherry-picking > > pain. Especially with a fast moving project like Arrow. > > > > What do others think? > > >
