On Thu, 18 Jan 2018 at 21:39 Benjamin Peterson <benjamin@python.org> wrote:

+1 to both of your specific proposals.

More generally, I think it makes good sense to allow dropping support for a platform in the next major Python release after vendor support for the platform stops. Even we say we support something, it will break quickly without buildbot validation.

+1 from me as well. We all only have so much bandwidth and if someone wants extended support there are plenty of contractors who could be hired to extend it. -Brett

On Thu, Jan 18, 2018, at 12:27, Victor Stinner wrote:

...

Hi,

I'm working on a exhaustive list of platforms supported by Python:

http://vstinner.readthedocs.io/cpython.html#supported-platforms

I noticed that the extended support phase of Windows Vista is expired, so I proposed to drop Vista support:

"Drop support of Windows Vista in Python 3.7" https://bugs.python.org/issue32592 https://github.com/python/cpython/pull/5231

Python has an explicit policy for Windows support, extract of the PEP 11:

"CPython’s Windows support now follows [Microsoft product support lifecycle]. A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired. Subsequent bug fix releases will support the same Windows releases as the original feature release (even if the extended support phase has ended)."

For Linux and FreeBSD, we have no explicit rule. CPython code base still contains code for FreeBSD 4... but FreeBSD 4 support ended longer than 10 years ago (January 31, 2007). Maybe it's time to drop support of these old platforms to cleanup the CPython code base to ease its maintainance.

I proposed: "Drop FreeBSD 9 and older support:"

https://bugs.python.org/issue32593 https://github.com/python/cpython/pull/5232

FreeBSD 9 supported ended 1 year ago (December 2016).

FreeBSD support:

https://www.freebsd.org/security/ https://www.freebsd.org/security/unsupported.html

CPython still has compatibility code for Linux 2.6, whereas the support of Linux 2.6.x ended in August 2011, longer than 6 years ago. Should we also drop support for old Linux kernels? If yes, which ones? The Linux kernel has LTS version, the oldest is Linux 3.2 (support will end in May, 2018).

Linux kernel support:

https://www.kernel.org/category/releases.html

Note: I'm only talking about changing the future Python 3.7. We should have the same support policy than for Windows. If Python 3.x.0 supports a platform, this support should be kept in the whole lifetime of the 3.x cycle (until it's end-of-line).

Victor _______________________________________________ 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/benjamin%40python.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/brett%40python.org

On 1/19/2018 1:04 AM, Nathaniel Smith wrote:

On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner <victor.stinner@gmail.com> wrote:

...

CPython still has compatibility code for Linux 2.6, whereas the support of Linux 2.6.x ended in August 2011, longer than 6 years ago. Should we also drop support for old Linux kernels? If yes, which ones? The Linux kernel has LTS version, the oldest is Linux 3.2 (support will end in May, 2018).

Linux kernel support:

https://www.kernel.org/category/releases.html

RHEL 5 uses 2.6.28, and still has "extended life cycle support" until 2020, but I guess no-one should be running Python 3.7 on that. CentOS 6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL 6 with extended life cycle support). Redhat does ship and support 3.6 on CentOS/RHEL 6 through their "software collections" product, and presumably is planning to do the same for 3.7.

It is a little surprising to see a Redhat employee suggest dropping support for RHEL 6. Hopefully you know what you're doing :-)

Microsoft offers *paid* private support of some sort to corporations for publicly unsupported versions of Windows, such as xp and, we may expect, Vista. But we dropped support of xp and should, by policy, do so for Vista. I am not familiar with what Redhat does, but if it is similar, I think we should apply the same policy. -- Terry Jan Reedy

I asked if we should drop support for Linux kernel 2.6. I now consider that no, we should not. It's not worth it. A colleague proposed to setup a RHEL 6 buildbot which would test Python on Linux 2.6. 2018-01-19 10:26 GMT+01:00 Antoine Pitrou <solipsis@pitrou.net>:

What is the problem with supporting Linux 2.6?

It increases the code size base. This compatibility code has to be maintained. It would even be better to make sure that it's tested ;-)

Do we need to rely on newer features? (which ones?)

My pull request which removed support for FreeBSD 9 and older was quite large and so it was interesting to do it: https://github.com/python/cpython/commit/13ff24582c99dfb439b1af7295b401415e7... According to reactions on this thread, I'm not sure anymore that removing a few lines of C code is worth it compared to loosing support for Linux 2.6 which seems to be important for many users. Python has some fallback code for "recent" Linux features like SOCK_CLOEXEC, accept4(), getrandom(), epoll_create1(), open() and O_CLOEXEC, etc. The worst part is that Python has to check once per process that open() doesn't ignore O_CLOEXEC flag. It requires one extra syscall. But well, compared to the total number of syscalls just for "python3 -c pass", this syscall is likely negligible :-) Victor

On 19 January 2018 at 16:04, Nathaniel Smith <njs@pobox.com> wrote:

On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner <victor.stinner@gmail.com> wrote:

...

CPython still has compatibility code for Linux 2.6, whereas the support of Linux 2.6.x ended in August 2011, longer than 6 years ago. Should we also drop support for old Linux kernels? If yes, which ones? The Linux kernel has LTS version, the oldest is Linux 3.2 (support will end in May, 2018).

Linux kernel support:

https://www.kernel.org/category/releases.html

RHEL 5 uses 2.6.28, and still has "extended life cycle support" until 2020, but I guess no-one should be running Python 3.7 on that. CentOS 6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL 6 with extended life cycle support). Redhat does ship and support 3.6 on CentOS/RHEL 6 through their "software collections" product, and presumably is planning to do the same for 3.7.

It is a little surprising to see a Redhat employee suggest dropping support for RHEL 6. Hopefully you know what you're doing :-)

Red Hat's kernel version numbers describe the *oldest* code in that kernel, rather than the newest. So if Red Hat customers want to run a new version of CPython on an older version of RHEL, and the new version of CPython needs a particular kernel feature, then that turns into a backport request for that kernel capability (e.g. while there were multiple drivers for Red Hat backporting the getrandom() syscall the RHEL 7's 3.10 kernel, CPython was one of them: https://bugzilla.redhat.com/show_bug.cgi?id=1330000) So I think it makes sense to base python-dev's Linux kernel support policy on the community LTS streams for the Linux kernel - if a commercial Python vendor chooses to go beyond those dates they can, just as they may go beyond python-dev's nominal support dates for CPython itself. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia