On Mon, Jul 6, 2020 at 7:21 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote:
> My two cents: I think this should be a little more liberal. At beta 1, > freeze the addition of new features but continue to tweak the > implementation with code clean-ups, additional tests, algorithmic > improvements, and better docs. For many of the devs (and users), the first > time we get to exercise and interact with some of the new features is > during the beta — that is our chance to improve and stabilize it before it > goes out the door. If a new API proves awkward in some way, the time to > find out and improve it is during the beta. Ideally, we would like both > the API and implementation to mature a bit before the release (first draft > != final copy). A release candidate is different — that is close to an > across-the-board freeze. Once the release happens, bug fixes and > documentation tweaks will continue to be checked in for the next > micro-release. > I've occasionally left it up to Łukasz to add the "needs 3.9 backport" label to a PR of mine. That seems a good way to keep the release manager happy. :-) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/YXRVZUF2MP5KRPWWSBZL6D5XH2V5RNRY/ Code of Conduct: https://www.python.org/psf/codeofconduct/
