[python-committers] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!

R. David Murray rdmurray at bitdance.com
Tue Nov 22 10:20:27 EST 2016


On Tue, 22 Nov 2016 02:24:37 -0500, Ned Deily <nad at python.org> wrote:
> On Nov 22, 2016, at 02:02, Ned Deily <nad at 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


More information about the python-committers mailing list