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.
Side note: One problem we have is that so few people actually exercise the beta
and give useful feedback. To me, the chief value of a public beta is that
people get to try it out before everything is set it stone. And reason for
having multiple betas is so that we can iterate. If not, perhaps we should
just have a single beta, frozen except for bugfixes.
Raymond
___
python-committers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/EIXKURQS4HXHLMJM4LRIXODMJPON5SFR/
Code of Conduct: https://www.python.org/psf/codeofconduct/
