It’s true that as releases get closer to final, more people will start exercising them. However, you really don’t have to wait. I maintain “official” Linux (Ubuntu) Docker images that contain all the latest releases (including alphas and betas), and the git head of the development branch at the time of the image builds.
https://gitlab.com/python-devs/ci-images/-/tree/master
I keep these up-to-date on every new maintenance release, alpha, beta, rc, and final, for Python 2.7, and 3.4 through 3.10. I use this image in my own open source code’s CI, and you can too! Unfortunately, we can’t do the same with Windows, but I’ve cracked the nut to get pretty good coverage for Windows releases too. Here for example is flufl.lock’s .gitlab-ci.yml file:
https://gitlab.com/warsaw/flufl.lock/-/blob/master/.gitlab-ci.yml
I need to extend that to 3.9 pre-releases, via python.org downloads rather than nuget.
So, it’s entirely possible to test your stuff against pre-release versions, and I highly encourage it.
That said, I also think that the general rule of only bug fix changes post beta 1 is the right policy. For other changes, or anything that you think straddles the line between bug fix and non-bug fix, ask the Release Manager. The RM’s primary role at this time is to ensure the stability of the final release. Their judgement is critical to the success of the final release, so ask! CC the RM on the PR and request their approval and comment.
I’ll also say that I personally give the RM a lot of latitude and authority to unilaterally revert any change they are not comfortable with. If the change author and RM cannot agree on whether a post-beta change is appropriate, you can escalate to the Steering Council.
Cheers, -Barry
On Jul 6, 2020, at 19:21, Raymond Hettinger raymond.hettinger@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.
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 -- python-committers@python.org To unsubscribe send an email to python-committers-leave@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/E... Code of Conduct: https://www.python.org/psf/codeofconduct/