On 30 Sep 2019, at 20:43, Terry Reedy email@example.com wrote:
On 9/30/2019 3:48 AM, Łukasz Langa wrote:
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
In the past, x.y.zrc1 has been tagged and branched somehow so that commits to x.y are commits to x.y.z+, the future x.y.(z+1). (I never paid attention to the details). For instance, 3.7 is currently 3.7.4+. As soon as Ned makes 3.7.5rc1, commits to 3.7 will go to 3.7.5+, the future 3.7.6, and will not disturb 3.7.5rc1 until Ned cherry picks them into the rc branch for 3.7.5.
Similarly, 3.8 is currently 3.8.b4+. As soon as you make 3.8.0rc1, if you do it the same way x.y.0rc1 has been done before recently, 3.8 commits should go to 3.8.0+, the future 3.8.1. Nothing should go into 3.8.0 until you pull it in or authorize it for those who know how to put it there (I don't). There should be no need to halt 3.8 activity.
Right, this is what we were doing and it's what we'll be doing this time around, too.
However, I feel that the release candidate for a .0 version is rather crucial. Cherry-picking changes to the gold release from an active support branch has non-zero risk of unexpected consequences. That can be due to non-trivial relationships between new commits or due to the release manager messing up the cherry-pick.
Another complication is a post-release merge conflict due to cherry picks.
This is why the overall recommendation I received from the more experienced release managers is that if there's too much activity on the branch we should release another preview. I agree with that, otherwise it gets too messy.
...but I don't want another RC if we can help it :-)