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. 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/archive%40mail-archive.com
Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
- Original Message - > From: "Serhiy Storchaka" > To: python-dev@python.org > Cc: python-committ...@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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
On Dec 19, 2018, at 12:42, Serhiy Storchaka 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.html -- Ned Deily n...@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/archive%40mail-archive.com
Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!
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 ___ 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/archive%40mail-archive.com
