3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-... We're reaching the end of the year and it's time for another pair of Python 3 maintenance releases, 3.7.2 and 3.6.8, before we ring out 2018. Since there are still some open release blocker issues and I haven't been bugging you about them, I've moved the code cutoff for the release candidates to this coming Friday, 12-07, by the end of the day (AOE). That gives us all another 4 days to review open issues and PRs. Please give highest attention to any release blockers you have been shepherding or reviewing. Thanks! A reminder: as previously announced, 3.6.8 is planned to be the last bugfix release of the 3.6 series. Python 3.6.0 was released on 2016-12-23, so by the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost exactly 2 years. When a new feature release is made and enters "bugfix" mode, our policy has long been to continue to maintain the previous bugfix branch for at least one more release and then move that branch to "security fix only" mode. 3.7.0 (and 3.6.6) was released nearly six months ago and, with the release of 3.6.8, there will have been two additional 3.6.x bugfix releases since then. So, barring any showstopper issues that might arise, the upcoming 3.6.8rc1 is your last chance to make bugfix changes for 3.6.x. Following the successful release of 3.6.8, only security fixes will be accepted for the 3.6 branch and future 3.6.x releases will be source-only and scheduled as needed; no further binary installers will be produced for 3.6. Refer to the Dev Guide sections and release PEPs linked below for more information. https://devguide.python.org/devcycle/ https://devguide.python.org/#branchstatus https://www.python.org/dev/peps/pep-0494/ https://www.python.org/dev/peps/pep-0537/ -- Ned Deily nad@python.org -- []
On Dec 4, 2018, at 03:42, Ned Deily <nad@python.org> wrote:
https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-...
An update: as of the planned Friday cutoff, we still had a few open issues. Since 3.6.8 is the last planned bugfix for the 3.6 branch, I would like to make sure we leave it in as good a state as possible before it moves to security-fix-only mode. Also, the Windows App Store support for 3.7.x that Steve D has been working on is in final review and it would be great to have that in the release candidate. So I'm going to extend the cutoff for 3.7.2rc1 and 3.6.8rc1 until **Monday, 12-10, end of day (AOE**), in other words **about 30 hours from now**. Thanks for all your efforts so far!
We're reaching the end of the year and it's time for another pair of Python 3 maintenance releases, 3.7.2 and 3.6.8, before we ring out 2018. Since there are still some open release blocker issues and I haven't been bugging you about them, I've moved the code cutoff for the release candidates to this coming Friday, 12-07, by the end of the day (AOE). That gives us all another 4 days to review open issues and PRs. Please give highest attention to any release blockers you have been shepherding or reviewing. Thanks!
A reminder: as previously announced, 3.6.8 is planned to be the last bugfix release of the 3.6 series. Python 3.6.0 was released on 2016-12-23, so by the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost exactly 2 years. When a new feature release is made and enters "bugfix" mode, our policy has long been to continue to maintain the previous bugfix branch for at least one more release and then move that branch to "security fix only" mode. 3.7.0 (and 3.6.6) was released nearly six months ago and, with the release of 3.6.8, there will have been two additional 3.6.x bugfix releases since then. So, barring any showstopper issues that might arise, the upcoming 3.6.8rc1 is your last chance to make bugfix changes for 3.6.x. Following the successful release of 3.6.8, only security fixes will be accepted for the 3.6 branch and future 3.6.x releases will be source-only and scheduled as needed; no further binary installers will be produced for 3.6. Refer to the Dev Guide sections and release PEPs linked below for more information.
https://devguide.python.org/devcycle/ https://devguide.python.org/#branchstatus https://www.python.org/dev/peps/pep-0494/ https://www.python.org/dev/peps/pep-0537/
-- Ned Deily nad@python.org -- []
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/nad%40python.org
-- Ned Deily nad@python.org -- []
https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-... OK, thanks to a lot of hard work by many of you, I think we are ready to start the manufacturing of **3.7.2rc1** and **3.6.8rc1**. For the **3.7 branch**, as usual feel free to continue to merge the usual changes appropriate for a `bugfix` branch; unless otherwise marked and agreed on as a **release blocker** for 3.7.2 final, any new 3.7 merges will be released in 3.7.3. For the **3.6 branch**, as announced 3.6.8 is planned to be **the last bugfix release** for the 3.6 series; future 3.6.x releases will be as needed and contain **only security fixes** and source only. Of course, if any release blocker regressions show up after 3.6.8rc1, we will consider merging fixes for them. This means that, **as of now, the 3.6 branch is no longer open to normal bugfixes**, only security fixes and release blocker regressions fixes and only with the approval of the release manager. Therefore, as we have done with previous branches moving to security-fix mode, merges to the 3.6 branch on the `cpython` GitHub repo are now restricted to the release managers. If you feel a change to 3.6 is needed either because it is a **release blocker regression** in 3.6.8 or because it is a **security issue**, please ensure there is a bpo issue describing the problem, mark it as **release blocker** priority, and submit the necessary PR. At some point, on or after the 3.6.8 release, we will be going through the open 3.6 PRs, open PRs with the `needs backport to 3.6` label, and bpo issues marked for 3.6 and updating or closing them as needed. **Please do not mark new PRs with the** `needs backport to 3.6` **label** unless you feel the proposed change meets one of the criteria above. Thanks for your help! -- Ned Deily nad@python.org -- []
04.12.18 10:42, Ned Deily пише:
A reminder: as previously announced, 3.6.8 is planned to be the last bugfix release of the 3.6 series. Python 3.6.0 was released on 2016-12-23, so by the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost exactly 2 years. When a new feature release is made and enters "bugfix" mode, our policy has long been to continue to maintain the previous bugfix branch for at least one more release and then move that branch to "security fix only" mode. 3.7.0 (and 3.6.6) was released nearly six months ago and, with the release of 3.6.8, there will have been two additional 3.6.x bugfix releases since then. So, barring any showstopper issues that might arise, the upcoming 3.6.8rc1 is your last chance to make bugfix changes for 3.6.x. Following the successful release of 3.6.8, only sec urity fixes will be accepted for the 3.6 branch and future 3.6.x releases will be source-only and scheduled as needed; no further binary installers will be produced for 3.6. Refer to the Dev Guide sections and release PEPs linked below for more information.
Can we revise our policy and prolong the bug fixing mode for 3.6? 3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several important syntax features it can be a minimal required version for long time. I merged several PRs before releasing 3.6.8rc1, but there are still less trivial bugfix PRs which need more time for reviewing, and there are bugs for which no PR is created yet. There is also a number of documentation PRs. I propose to allow backporting bugfixes to 3.6 if they do not need excessive work, but stop to fix 3.6 only bugs. After migrating to GitHab, backporting became less painful, most of backports to 3.6 can be done automatically from master or from 3.7.
----- Original Message -----
From: "Serhiy Storchaka" <storchaka@gmail.com> To: python-dev@python.org Cc: python-committers@python.org Sent: Wednesday, December 19, 2018 10:14:41 AM Subject: Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
04.12.18 10:42, Ned Deily пише:
A reminder: as previously announced, 3.6.8 is planned to be the last bugfix release of the 3.6 series. Python 3.6.0 was released on 2016-12-23, so by the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost exactly 2 years. When a new feature release is made and enters "bugfix" mode, our policy has long been to continue to maintain the previous bugfix branch for at least one more release and then move that branch to "security fix only" mode. 3.7.0 (and 3.6.6) was released nearly six months ago and, with the release of 3.6.8, there will have been two additional 3.6.x bugfix releases since then. So, barring any showstopper issues that might arise, the upcoming 3.6.8rc1 is your last chance to make bugfix changes for 3.6.x. Following the successful release of 3.6.8, only sec urity fixes will be accepted for the 3.6 branch and future 3.6.x releases will be source-only and scheduled as needed; no further binary installers will be produced for 3.6. Refer to the Dev Guide sections and release PEPs linked below for more information.
Can we revise our policy and prolong the bug fixing mode for 3.6? 3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several important syntax features it can be a minimal required version for long time.
That would actually be a great move, even if it doesn't happen, thanks for considering it.
I merged several PRs before releasing 3.6.8rc1, but there are still less trivial bugfix PRs which need more time for reviewing, and there are bugs for which no PR is created yet. There is also a number of documentation PRs. I propose to allow backporting bugfixes to 3.6 if they do not need excessive work, but stop to fix 3.6 only bugs. After migrating to GitHab, backporting became less painful, most of backports to 3.6 can be done automatically from master or from 3.7.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/cstratak%40redhat.com
-- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat
Hi, I am working in the Red Hat "Python-maint" team which is maintaining Python 3.6 as the main Python interpreter in RHEL 8, which will likely be supported for at least 10 years. And we have been supporting Python 2.7 in RHEL 7. So obviously, being able to benefit of the upstream effort and infra to have a Python 3.6 Long Time Support (LTS) would help us :-) The question is more who else would benefit from that and is it worth it? I don't want Python upstream to pay the price of the maintenance burden of RHEL 8 lifecycle. For example, supporting a version means to have a working CI (Travis CI, AppVeyor, VSTS, buildbots). I would suggest to only support a very few platforms for the LTS. I propose to restrict to Linux. It doesn't mean to break other platforms on purpose, just to restrict CI to the bare minimum. If Microsoft is interested, we can also support Windows as well. RHEL 7 is based on Python 2.7.5 which has been released in 2013 (5 years ago) and there are 150 patches on top of it: it means that around 30 patches are added per year. I would suggest to have a very strict policy on which changes are backported into 3.6: only the most critical bugfixes, but all security fixes obviously. If we extend Python 3.6 lifetime, do we need a new release manager when the initial lifetime (usually 5 years) ends? Benjamin Peterson accepted to be the Python 2.7 release manager for 10 years (instead of 5 years initially). We could ask Ned Deily about Python 3.6 LTS :-) We would need a group of people reviewing individual 3.6 pull requests to decide to pick them or not. I would volunteer to review these PRs and merge them. The idea isn't new, Nick Coghlan proposed a "ELPython" last year: https://github.com/elpython/elpython-meta The Linux kernel also have multiple LTS kernel which are supported longer than usual releases: they are now supported for 6 years. See "Longterm" at: https://www.kernel.org/category/releases.html Victor -- Night gathers, and now my watch begins. It shall not end until my death.
I’m all for extending the life of 3.6, it sure feels recent to me!
3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several important syntax features it can be a minimal required version for long time.
Which is a good argument for why we may not need longer term support for 3.5, but minimum requirement doesn’t mean we need to support it longer term, as the alternative is to upgrade to 3.7 — and most code that works on 3.6 will work on 3.7, yes? That is — if you want recent bug fixes, upgrade your Python. If you have a working 3.6 based system, you only need security fixes, yes? I fully understand the need to keep a working older system up to date with security fixes, but I’ve always been confused by the desire to run an older base system, while still requiring newer subsystems, whether that’s an older Linux with a newer python, or and older python with a newer package. -CHB
I merged several PRs before releasing 3.6.8rc1, but there are still less trivial bugfix PRs which need more time for reviewing, and there are bugs for which no PR is created yet. There is also a number of documentation PRs. I propose to allow backporting bugfixes to 3.6 if they do not need excessive work, but stop to fix 3.6 only bugs. After migrating to GitHab, backporting became less painful, most of backports to 3.6 can be done automatically from master or from 3.7.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
19.12.18 19:01, Chris Barker - NOAA Federal via Python-Dev пише:
3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several important syntax features it can be a minimal required version for long time.
Which is a good argument for why we may not need longer term support for 3.5, but minimum requirement doesn’t mean we need to support it longer term, as the alternative is to upgrade to 3.7 — and most code that works on 3.6 will work on 3.7, yes?
No. There were several minor potentially breaking changes. The most famous one is making "async" a keyword. Different libraries were broken for different causes, and the end user code can be broken too. AFAIK the popular package tensorflow is not 3.7 compatible for today.
On Dec 19, 2018, at 12:42, Serhiy Storchaka <storchaka@gmail.com> wrote:
19.12.18 19:01, Chris Barker - NOAA Federal via Python-Dev пише:
[ extending 3.6 bugfix release phase? ] [...] [...]
FYI, the discussion of this topic has proceeded to a conclusion on the python-committers mailing list. TL;DR we are not going to change our plans now. Thanks for all the thoughtful comments! https://mail.python.org/pipermail/python-committers/2018-December/006487.htm... -- Ned Deily nad@python.org -- []
On 12/19/2018 4:14 AM, Serhiy Storchaka wrote: I propose to allow backporting bugfixes to 3.6 if
they do not need excessive work, but stop to fix 3.6 only bugs.
I think this would need a PEP.
After migrating to GitHab, backporting became less painful,
Before GitHub, we forward ported. For me, for idlelib, that was faster, though the current automation makes it about equal effort. The main pain point for non-IDLE patches was NEWS conflicts, which have been eliminated.
most of backports to 3.6 can be done automatically from master or from 3.7.
That is true in part because all bugfixes are backported, so that most of the code in most modules is the same in 3.7 and 3.6. As soon as some bugfixes are not backported, nearby bug fixes start getting conflicts they would not have gotten otherwise. For idlelib, I know that if some PRs are not backported (which currently *is* trivial), then it will cease being trivial for every patch. As it is, 2 PRs that touch the same module can conflict, so that one requires editing when the other is merged. I often delay writing a followup PR until the first is merged. -- Terry Jan Reedy
participants (6)
-
Charalampos Stratakis
-
Chris Barker - NOAA Federal
-
Ned Deily
-
Serhiy Storchaka
-
Terry Reedy
-
Victor Stinner