> > I'd be happier with something concrete like the following expected release > flow: > > 1) We freeze a branch > 2) To hit RC, we need green circle + no regression on ASF (or green ASF in > the future when stable) > 3) We need N weeks in this frozen state for people to test it out > 4) Once we have both 2 and 3, we RC and GA >
Yeah, I was thinking (1) would include the beta1 release if we're already green, i.e. meaning we'd skip (2), or alpha1 if not yet green. 3) would still hold, but would be N weeks from first beta to first rc. That is, something like… 1) branch. if green cut beta1 else cut alpha1 1a) when green then cut beta1 2) wait N weeks from beta1. if no blockers cut rc1 3) wait 2 weeks. if no blockers cut GA As evident from both 4.0 and 4.1 the alpha to beta timeframe hurts, and our Stable Trunk (and CI) efforts are to minimise/remove this. That is, this incentivises us to get on top of CI issues and flakies ahead of branch time. Is it too prescriptive to say "we'll be frozen on a branch for at least 8 > weeks so folks can test out the betas"? (I ask because I know I can get a > little "structure-happy" at times). > 6-8 weeks feels right, if we want to be prescriptive. And there needs to be a sense of urgency when we make this call to action to downstream testers. As a release manager I know that an error margin of two weeks is typical.
