On Nov 22, 2016, at 12:59, Brett Cannon <br...@python.org> wrote: > I think for me what made everything click was realizing that we used to say > "until rc1 is cut, treat it as the beta phase", while Ned is saying "since b4 > is the last beta, we are now working towards the RC". I actually think Ned's > approach is mentally more consistent as we are always working towards the > next release which should specify the commit rules, while historically we > have worked as if the *last* release dictated the commit rules *unless* it > was for the final release.
Yes, thanks, Brett! That is indeed my way of thinking about the release and I think it is also consistent with how we describe the Release Candidate stage in the Developer's Guide. "A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point." https://docs.python.org/devguide/devcycle.html#release-candidate-rc But, as you hint at, that is not really the case for the Beta stage which is described thusly: "After a first beta release is published, no new features are accepted. Only bug fixes can now be committed. This is when core developers should concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta releases" https://docs.python.org/devguide/devcycle.html#release-candidate-rc Up until you pointed this out, I hadn't noticed the discrepancy between those two transitions, Alpha -> Beta and Beta -> RC. I guess for me the name "Release Candidate" makes the "working towards the RC" approach very natural. But it also seems natural to me to think of the first Beta release as the feature code cutoff (as we currently do) rather the last Alpha being the feature code cutoff and working towards the first Beta. Perhaps we can live with that bit of inconsistency? :=) We certainly could change that if enough of us find it too confusing. The good news is that we'll have another chance to tweak things for the 3.7 release when, with the new development workflow, we should have more sophisticated tools available to manage the release endgame. I'm hopeful we'll be able to make it easier for all of us. -- Ned Deily n...@python.org -- [] _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
