![](https://secure.gravatar.com/avatar/f9c4ab38a9ced1923ff1bf6e3553a029.jpg?s=120&d=mm&r=g)
On Tue, 22 Nov 2016 02:24:37 -0500, Ned Deily <nad@python.org> wrote:
On Nov 22, 2016, at 02:02, Ned Deily <nad@python.org> wrote:
On behalf of the Python development community and the Python 3.6 release team, I'm pleased to announce the availability of Python 3.6.0b4. 3.6.0b4 is the last planned beta release of Python 3.6, the next major release of Python. [...]
OK, all of the release engineering for 3.6.0b4 is complete. The 3.6 branch in the cpython repo is now available again but, as noted, *only* for reviewed release critical fixes appropriate for the 3.6.0 final and for final 3.6.0 doc updates!
Again, until 3.6.0rc1 is tagged, scheduled to happen in two weeks on 2016-12-05, please do *not* push non release-critical code of any kind to the 3.6 branch; after rc1 is tagged, the 3.6 branch will be open for 3.6.1 changes. Please use these two weeks to thoroughly review and, as necessary, update the What's New In Python 3.6 document (thanks, Elvis and Yuri, for editing it once again!) and all other release documentation.
Any additional testing you can do and/or encourage others to do of the new and old components of 3.6 and with with third-party packages will be appreciated. Please document anything you think *might* be a release critical problem in the bug tracker marking them as "release blocker". Assuming no unresolved release critical problems arise, the final two steps will be the release candidate in 2 weeks and then, again assuming no release critical problems are identified in it, the final release on 12-16.
Please contact me if you have any questions about what may or may not be appropriate to push during these final days before the release.
I'm sorry, but I find this confusing. It wasn't what I understood your previous email to mean, which means I didn't read it carefully enough and saw it through a filter of my preconceptions.
Essentially, you are making B4 act like RC1 except that you are expecting there to be fixes, and making RC1 act like RC2 with hopes that it really is final. That's fine, but we really ought to have named them RC1 and RC2 in that case.
I'm not suggesting you change your plan now, except that you should *not* open the 3.6 branch for commits until after *final* is released, in case another RC is required. Unless you plan to branch and cherry pick for an "RC2" if it is needed, which would be fine, but you should say that :)
If we in fact miss something in this really-an-RC phase (RC0?) that is revealed by the testing of RC1, then I strongly recommend against making changes to RC1 and then releasing the result as final without external testing. We've had a brown bag release in the past by doing that, for what we thought were "safe" fixes. Any "extra" RC period can be really short, though.
--David