Python 3.6 Release Schedule Details
FYI - I've just updated PEP 494 with a fleshed-out 3.6.0 release schedule. The 3.6 schedule is generally similar to the successful 18-month development and release cycle used in recent releases but with a few significant changes. The main difference is that the 3.6 schedule takes advantage of the earlier creation of the 3.5 branch (Thanks, Larry!), which allowed code for 3.6 to be checked in starting at 3.5.0beta1, rather than later at release candidate 1 as in previous release cycles. This provides an additional 11 weeks of overlap between 3.5.0 and 3.6.0, accelerating the release date for 3.6.0 without significantly reducing the overall release cycle duration.
Another change has been to add a fourth beta and drop the third release candidate. My gut feeling from the past several releases is that a lot of feature code does not get checked in until close to the b1 feature code cutoff so that extending the beta phase should result in more testing exposure for all features. And I would like to reduce the amount of churn during the release candidate phase: a worthy goal is to make no changes after rc1, so that an rc2 would be be made only if absolutely necessary.
Also note that the alpha1 build is scheduled for two weeks before PyCon 2016 and alpha2 will occur a week after the conclusion of the PyCon development sprints. Beta1, the feature code cutoff, occurs at the beginning of September just after the US Labor Day holiday and the traditional end of summer, with the final release in mid-December 2016.
A comparison between the 3.5.0 and 3.6.0 release cycles shows the differences (in days):
phase 3.5.0 3.6.0
====== ===== =====
dev 363 357
alpha 105 114
beta 77 89
rc 35 14
total 580 574As always, the schedule will be subject to changes as necessary - and comments welcomed - but I'm hoping that with this schedule we will be able to once again achieve a high-quality release and still be able to move the release date up without straining our development, testing, and release team resources. So keep those PEPs, other features, and bug fixes coming in. In the immortal words of Larry: "Let the wild rumpus begin!"
--Ned
PEP: 494 Title: Python 3.6 Release Schedule Last-Modified: 01-Oct-2015 Author: Ned Deily nad@acm.org Status: Active Type: Informational Content-Type: text/x-rst Created: 30-May-2015 Python-Version: 3.6
Abstract
This document describes the development and release schedule for Python 3.6. The schedule primarily concerns itself with PEP-sized items.
Release Manager and Crew
- 3.6 Release Manager: Ned Deily
- Windows installers: Steve Dower
- Mac installers: Ned Deily
- Documentation: Georg Brandl
3.6 Lifespan
3.6 will receive bugfix updates approximately every 3-6 months for approximately 18 months. After the release of 3.7.0 final, a final 3.6 bugfix update will be released. After that, it is expected that security updates (source only) will be released until 5 years after the release of 3.6 final, so until approximately December 2021.
Release Schedule
3.6.0 schedule
- 3.6 development begins: 2015-05-24
- 3.6.0 alpha 1: 2016-05-15
- 3.6.0 alpha 2: 2016-06-12
- 3.6.0 alpha 3: 2016-07-10
- 3.6.0 alpha 4: 2016-08-07
- 3.6.0 beta 1: 2016-09-07
(No new features beyond this point.)
- 3.6.0 beta 2: 2016-10-02
- 3.6.0 beta 3: 2016-10-30
- 3.6.0 beta 4: 2016-11-20
- 3.6.0 candidate 1: 2016-12-04
- 3.6.0 candidate 2 (if needed): 2016-12-11
- 3.6.0 final: 2016-12-16
Features for 3.6
Proposed changes for 3.6:
- PEP 447, Add __getdescriptor__ method to metaclass
- PEP 498, Literal String Formatting
- PEP 499, python -m foo should bind sys.modules['foo'] in additon to sys.modules['__main__']
- PEP 501, Translation ready string interpolation
Copyright
This document has been placed in the public domain.
-- Ned Deily nad@acm.org -- []
On Thu, 01 Oct 2015 22:24:18 -0400, Ned Deily nad@acm.org wrote:
Another change has been to add a fourth beta and drop the third release candidate. My gut feeling from the past several releases is that a lot of feature code does not get checked in until close to the b1 feature code cutoff so that extending the beta phase should result in more testing exposure for all features. And I would like to reduce the amount of churn during the release candidate phase: a worthy goal is to make no changes after rc1, so that an rc2 would be be made only if absolutely necessary.
I would like to be wrong, but I think this is unrealistic. The reality seems to be that there are a significant number of people (especially on the Windows side, if I'm guessing correctly) who do not test until we get to RC1. IIRC we had a number of changes between RC1 and RC2, and a non-trivial number of changes between RC2 and RC3 this time around.
That said, I do feel the amount of pre-release testing, even in the beta part of the cycle, has increased steadily in the past two or three releases, which is great to see.
--David
On Oct 2, 2015, at 10:20, R. David Murray rdmurray@bitdance.com wrote:
On Thu, 01 Oct 2015 22:24:18 -0400, Ned Deily nad@acm.org wrote:
Another change has been to add a fourth beta and drop the third release candidate. My gut feeling from the past several releases is that a lot of feature code does not get checked in until close to the b1 feature code cutoff so that extending the beta phase should result in more testing exposure for all features. And I would like to reduce the amount of churn during the release candidate phase: a worthy goal is to make no changes after rc1, so that an rc2 would be be made only if absolutely necessary.
I would like to be wrong, but I think this is unrealistic. The reality seems to be that there are a significant number of people (especially on the Windows side, if I'm guessing correctly) who do not test until we get to RC1. IIRC we had a number of changes between RC1 and RC2, and a non-trivial number of changes between RC2 and RC3 this time around.
I would like to be right but we won't know for sure either way until we get there. In 3.5.0, there were major changes to the Windows installation process and there is still some fallout from those changes that will be addressed in 3.5.1. I'm hopeful that most of those issues were one-time things and that we can also learn from 3.5.0. I plan to emphasize earlier testing of the betas and want to set expectations that, when we call something a release candidate, we really intend to be able to release it. If it's not ready, then we may need to do another beta. Release candidate releases are costly for all involved. I'd like to see us try real hard to keep them to a minimum.
That said, I do feel the amount of pre-release testing, even in the beta part of the cycle, has increased steadily in the past two or three releases, which is great to see.
Yes, it has. Also, some of the third-party distributors - Ubuntu and MacPorts come to mind - have been more aggressive about pushing betas and even alphas out for wider exposure. Anything we can do on the Windows side to help get more exposure earlier would be great, too.
-- Ned Deily nad@acm.org -- []
On 10/2/2015 3:41 PM, Ned Deily wrote:
On Oct 2, 2015, at 10:20, R. David Murray rdmurray@bitdance.com wrote:
On Thu, 01 Oct 2015 22:24:18 -0400, Ned Deily nad@acm.org wrote:
Another change has been to add a fourth beta and drop the third release candidate. My gut feeling from the past several releases is that a lot of feature code does not get checked in until close to the b1 feature code cutoff so that extending the beta phase should result in more testing exposure for all features. And I would like to reduce the amount of churn during the release candidate phase: a worthy goal is to make no changes after rc1, so that an rc2 would be be made only if absolutely necessary.
I would like to be wrong, but I think this is unrealistic. The reality seems to be that there are a significant number of people (especially on the Windows side, if I'm guessing correctly) who do not test until we get to RC1. IIRC we had a number of changes between RC1 and RC2, and a non-trivial number of changes between RC2 and RC3 this time around.
I would like to be right but we won't know for sure either way until we get there. In 3.5.0, there were major changes to the Windows installation process and there is still some fallout from those changes that will be addressed in 3.5.1. I'm hopeful that most of those issues were one-time things and that we can also learn from 3.5.0. I plan to emphasize earlier testing of the betas and want to set expectations that, when we call something a release candidate, we really intend to be able to release it. If it's not ready, then we may need to do another beta. Release candidate releases are costly for all involved. I'd like to see us try real hard to keep them to a minimum.
I agree with making the effort. I believe there have been releases with just 2 rcs. The schedule looks good to me.
tjr
On 3 October 2015 at 05:41, Ned Deily nad@acm.org wrote:
On Oct 2, 2015, at 10:20, R. David Murray rdmurray@bitdance.com wrote:
That said, I do feel the amount of pre-release testing, even in the beta part of the cycle, has increased steadily in the past two or three releases, which is great to see.
Yes, it has. Also, some of the third-party distributors - Ubuntu and MacPorts come to mind - have been more aggressive about pushing betas and even alphas out for wider exposure. Anything we can do on the Windows side to help get more exposure earlier would be great, too.
We also looked at trying to land 3.5 for this month's Fedora 23 release (which would have involved bringing the pre-releases into Fedora Rawhide), but decided it more sense to prioritise further work on the Python 3 migration instead. That competing task won't be there for the 3.6 release, so with any luck the draft release schedule should align nicely with bringing at least the release candidates, and potentially one or more of the later beta releases, into Fedora Rawhide for F26.
On the Windows front, might it be worth considering setting up semi-automated MSI installer testing on Appveyor? http://www.appveyor.com/docs/build-configuration#installing-additional-softw... indicates it should be able to do installations from the python.org binaries, and it could be triggered from a repo containing download URLs for the installers to be tested (for example).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Oct 03, 2015, at 11:28 PM, Nick Coghlan wrote:
We also looked at trying to land 3.5 for this month's Fedora 23 release (which would have involved bringing the pre-releases into Fedora Rawhide), but decided it more sense to prioritise further work on the Python 3 migration instead.
It's almost as if there's a Linux Cabal[*] dividing and conquering! We pushed hard for the 3.5 migration in the very soon to be released Ubuntu 15.10, found, fixed, and forwarded lots of bugs, and feel pretty good about the state of Python 3.5. Yes, there's a long tail and some difficult packages, but a lot got fixed both in Debuntu and upstream. That'll continue but I'm planning for the bulk of our next cycle to be Python 3 by default and dropping 3.4. As for Debian, which is release-when-ready, I'd also like us to be Python 3 by default and 3.5 only. The 3.5 transition is just starting over there (mostly rebuilds since Ubuntu diffs have been pushed upstream to Debian wherever possible).
Cheers, -Barry
On 4 October 2015 at 00:31, Barry Warsaw barry@python.org wrote:
It's almost as if there's a Linux Cabal[*] dividing and conquering!
Who, us? :)
(Actually, mostly *not* me - I'm mainly a cheerleader, while folks like Slavek Kabrda, Robert Kuska, Petr Viktorin, Matej Stuchlik, Miro Hroncok, Thomas Spura, and everyone else with the Fedora Python 3 porting badge [1,2] have done the actual work in Fedora/EPEL, while folks like Victor Stinner, Christian Heimes, and Maciej Szulik have been tackling aspects higher up the stack in OpenStack/FreeIPA/OpenShift)
We pushed hard for the 3.5 migration in the very soon to be released Ubuntu 15.10, found, fixed, and forwarded lots of bugs, and feel pretty good about the state of Python 3.5. Yes, there's a long tail and some difficult packages, but a lot got fixed both in Debuntu and upstream.
Yeah, likewise on the Fedora side (including getting a long way down the road towards porting Samba's Python components).
That'll continue but I'm planning for the bulk of our next cycle to be Python 3 by default and dropping 3.4. As for Debian, which is release-when-ready, I'd also like us to be Python 3 by default and 3.5 only. The 3.5 transition is just starting over there (mostly rebuilds since Ubuntu diffs have been pushed upstream to Debian wherever possible).
In addition to upgrading the Fedora stack to 3.5 and then getting that into EPEL 7, one of our other objectives will be to continue to improve the usability of the Software Collections model (so it's easier for folks to go from system Python -> Python 2.7 SCL -> Python 3.5 SCL, regardless of whether they're on RHEL/CentOS 6 or 7).
The system Python in RHEL/CentOS *will* be switching to Python 3 at some point, but we don't want folks developing user space applications on those platforms to wait that long to switch - between Software Collections and parallel Python 3 stacks in EPEL, we should hopefully be able to get most of those migrated well before the RHEL 7 EOL in 2024.
Cheers, Nick.
[1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default#Owner [2] https://badges.fedoraproject.org/badge/parselmouth
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Barry Warsaw -
Ned Deily -
Nick Coghlan -
R. David Murray -
Terry Reedy