iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 11: define tiered platform support (#2442)

This commit is contained in:
Brett Cannon 2022-04-18 14:57:20 -07:00 committed by GitHub
parent 42e241fac4
commit 0806d5200b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 154 additions and 100 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

254
pep-0011.txt
View File

@ -1,5 +1,5 @@
PEP: 11 PEP: 11
Title: Removing support for little used platforms Title: CPython platform support
Version: $Revision$ Version: $Revision$
Last-Modified: $Date$ Last-Modified: $Date$
Author: Martin von Löwis <martin@v.loewis.de>, Author: Martin von Löwis <martin@v.loewis.de>,
@ -14,76 +14,180 @@ Post-History: 18-Aug-2007,
Abstract Abstract
-------- ========
This PEP documents how an operating system (platform) becomes This PEP documents how an operating system (platform) becomes
supported in CPython and documents past support. supported in CPython, what platforms are currently supported, and
documents past support.
Rationale Rationale
--------- =========
Over time, the CPython source code has collected various pieces of Over time, the CPython source code has collected various pieces of
platform-specific code, which, at some point in time, was platform-specific code, which, at some point in time, was
considered necessary to use Python on a specific platform. considered necessary to use CPython on a specific platform.
Without access to this platform, it is not possible to determine Without access to this platform, it is not possible to determine
whether this code is still needed. As a result, this code may whether this code is still needed. As a result, this code may
either break during Python's evolution, or it may become either break during CPython's evolution, or it may become
unnecessary as the platforms evolve as well. unnecessary as the platforms evolve as well.
The growing amount of these fragments poses the risk of Allowing these fragments to grow poses the risk of
unmaintainability: without having experts for a large number of unmaintainability: without having experts for a large number of
platforms, it is not possible to determine whether a certain platforms, it is not possible to determine whether a certain
change to the CPython source code will work on all supported change to the CPython source code will work on all supported
platforms. platforms.
To reduce this risk, this PEP specifies what is required for a To reduce this risk, this PEP specifies what is required for a
platform to be considered supported by Python as well as providing a platform to be considered supported by CPython as well as providing a
procedure to remove code for platforms with few or no Python procedure to remove code for platforms with few or no CPython
users. users.
Supporting platforms This PEP also lists what plaforms *are* supported by the CPython
-------------------- interpreter. This lets people know what platforms are directly
supported by the CPython development team.
Gaining official platform support requires two things. First, a core
developer needs to volunteer to maintain platform-specific code. This
core developer can either already be a member of the Python
development team or be given contributor rights on the basis of
maintaining platform support (it is at the discretion of the Python
development team to decide if a person is ready to have such rights
even if it is just for supporting a specific platform).
Second, a stable buildbot must be provided [2]_. This guarantees that Support tiers
platform support will not be accidentally broken by a Python core =============
developer who does not have personal access to the platform. For a
buildbot to be considered stable it requires that the machine be
reliably up and functioning (but it is up to the Python core
developers to decide whether to promote a buildbot to being
considered stable).
This policy does not disqualify supporting other platforms Platform support is broken down into *tiers*. Each tier comes with
indirectly. Patches which are not platform-specific but still done to different requirements which lead to different promises being made
add platform support will be considered for inclusion. For example, about support.
if platform-independent changes were necessary in the configure
script which were motivated to support a specific platform that could To be promoted to a tier, steering council support is required and is
be accepted. Patches which add platform-specific code such as the expected to be driven by team consensus. Demotion to a lower tier
name of a specific platform to the configure script will generally occurs when the requirements of the current tier are no longer met for
not be accepted without the platform having official support. a platform for an extended period of time based on the judgment of
the release manager or steering council. For platforms which no longer
meet the requirements of any tier by b1 of a new feature release, an
announcement will be made to warn the community of the pending removal
of support for the platform (e.g. in the b1 announcement). If the
platform is not brought into line for at least one of the tiers by the
first release candidate, it will be listed as unsupported in this PEP.
Tier 1
------
- `CI failures <https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__ block releases.
- Changes which would break the ``main`` branch are not allowed to be merged;
any breakage should be fixed or reverted immediately.
- All core developers are responsible to keep ``main``, and thus these
platforms, working.
- Failures on these platforms **block a release**.
======================== =====
Target Triple Notes
======================== =====
i686-pc-windows-msvc
x86_64-pc-windows-msvc
x86_64-apple-darwin BSD libc, clang
x86_64-unknown-linux-gnu glibc, gcc
======================== =====
Tier 2
------
- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be **fixed or
reverted within 24 hours**.
- Failures on these platforms **block a release**.
=========================== ========================== ============================================== ========
Target Triple Notes Buildbot Contacts
=========================== ========================== ============================================== ========
aarch64-apple-darwin clang https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren, Dong-he Na
aarch64-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner
glibc, clang https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P. Smith
powerpcle-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/90 Petr Viktorin, Victor Stinner
x86_64-unknownlinux-gnu glibc, clang https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P. Smith
=========================== ========================== ============================================== ========
Tier 3
------
- Must have a reliable buildbot.
- At least **one** core developer is signed up to support the platform.
- No response SLA to failures.
- Failures on these platforms do **not** block a release.
============================== =========================== ============================================== ========
Target Triple Notes Buildbot Contacts
============================== =========================== ============================================== ========
aarch64-pc-windows-msvc https://buildbot.python.org/all/#/builders/729 Steve Dower
powerpcle-unknown-linux-gnu glibc, clang https://buildbot.python.org/all/#/builders/435 Victor Stinner
x86_64-unknown-freebsd BSD libc, clang https://buildbot.python.org/all/#/builders/172 Victor Stinner
armv7l-unknown-linux-gnueabihf Raspberry Pi OS, glibc, gcc https://buildbot.python.org/all/#/builders/424 Gregory P. Smith
============================== =========================== ============================================== ========
All other platforms
-------------------
Support for a platform may be partial within the code base, such as
from active development around platform support or accidentally.
Code changes to platforms not listed in the above tiers may be rejected
or removed from the code base without a deprecation process if they
cause a maintenance burden or obstruct general improvements.
Platforms not listed here may be supported by the wider Python
community in some way. If your desired platform is not listed above,
please perform a search online to see if someone is already providing
support in some form.
Notes
-----
Microsoft Windows
'''''''''''''''''
Microsoft has established a policy called product support lifecycle
[1]_. Each product's lifecycle has a mainstream support phase, where
the product is generally commercially available, and an extended
support phase, where paid support is still available, and certain bug
fixes are released (in particular security fixes).
CPython's Windows support now follows this 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).
Each feature release is built by a specific version of Microsoft
Visual Studio. That version should have mainstream support when the
release is made. Developers of extension modules will generally need
to use the same Visual Studio release; they are concerned both with
the availability of the versions they need to use, and with keeping
the zoo of versions small. The CPython source tree will keep
unmaintained build files for older Visual Studio releases, for which
patches will be accepted. Such build files will be removed from the
source tree 3 years after the extended support for the compiler has
ended (but continue to remain available in revision control).
Legacy C Locale
'''''''''''''''
Starting with CPython 3.7.0, \*nix platforms are expected to provide
at least one of ``C.UTF-8`` (full locale), ``C.utf8`` (full locale) or
``UTF-8`` (``LC_CTYPE``-only locale) as an alternative to the legacy ``C``
locale.
Any Unicode-related integration problems that occur only in the legacy ``C``
locale and cannot be reproduced in an appropriately configured non-ASCII
locale will be closed as "won't fix".
CPU architecture and compiler support are viewed in a similar manner
as platforms. For example, to consider the ARM architecture supported
a buildbot running on ARM would be required along with support from
the Python development team. In general it is not required to have
a CPU architecture run under every possible platform in order to be
considered supported.
Unsupporting platforms Unsupporting platforms
---------------------- ======================
If a certain platform that currently has special code in CPython is If a platform drops out of tiered support, a note must be posted
deemed to be without enough Python users or lacks proper support from in this PEP that the platform is no longer actively supported. This
the Python development team and/or a buildbot, a note must be posted
in this PEP that this platform is no longer actively supported. This
note must include: note must include:
- the name of the system - the name of the system
@ -100,64 +204,14 @@ condition (usually a preprocessor symbol) that will become
unsupported. unsupported.
At the same time, the CPython source code must be changed to At the same time, the CPython source code must be changed to
produce a build-time error if somebody tries to install Python on produce a build-time error if somebody tries to install CPython on
this platform. On platforms using autoconf, configure must fail. this platform. On platforms using autoconf, configure must fail.
This gives potential users of the platform a chance to step This gives potential users of the platform a chance to step
forward and offer maintenance. forward and offer maintenance.
Re-supporting platforms
-----------------------
If a user of a platform wants to see this platform supported
again, they may volunteer to maintain the platform support. Such an
offer must be recorded in the PEP, and the user can submit patches
to remove the build-time errors, and perform any other maintenance
work for the platform.
Microsoft Windows
-----------------
Microsoft has established a policy called product support lifecycle
[1]_. Each product's lifecycle has a mainstream support phase, where
the product is generally commercially available, and an extended
support phase, where paid support is still available, and certain bug
fixes are released (in particular security fixes).
CPython's Windows support now follows this 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).
Because of this policy, no further Windows releases need to be listed
in this PEP.
Each feature release is built by a specific version of Microsoft
Visual Studio. That version should have mainstream support when the
release is made. Developers of extension modules will generally need
to use the same Visual Studio release; they are concerned both with
the availability of the versions they need to use, and with keeping
the zoo of versions small. The CPython source tree will keep
unmaintained build files for older Visual Studio releases, for which
patches will be accepted. Such build files will be removed from the
source tree 3 years after the extended support for the compiler has
ended (but continue to remain available in revision control).
Legacy C Locale
---------------
Starting with CPython 3.7.0, \*nix platforms are expected to provide
at least one of ``C.UTF-8`` (full locale), ``C.utf8`` (full locale) or
``UTF-8`` (``LC_CTYPE``-only locale) as an alternative to the legacy ``C``
locale.
Any Unicode-related integration problems that occur only in the legacy ``C``
locale and cannot be reproduced in an appropriately configured non-ASCII
locale will be closed as "won't fix".
No-longer-supported platforms No-longer-supported platforms
----------------------------- =============================
* | Name: MS-DOS, MS-Windows 3.x * | Name: MS-DOS, MS-Windows 3.x
| Unsupported in: Python 2.0 | Unsupported in: Python 2.0
@ -276,15 +330,15 @@ No-longer-supported platforms
| Code removed in: Python 3.7 | Code removed in: Python 3.7
References References
---------- ==========
.. [1] http://support.microsoft.com/lifecycle/ .. [1] http://support.microsoft.com/lifecycle/
.. [2] http://buildbot.python.org/3.x.stable/
Copyright Copyright
--------- =========
This document has been placed in the public domain. This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive.