PEP 11: define tiered platform support (#2442)
This commit is contained in:
Brett Cannon
GitHub
parent
42e241fac4
commit
0806d5200b
254
pep-0011.txt
254
pep-0011.txt
|
|
@ -1,5 +1,5 @@
|
|||
PEP: 11
|
||||
Title: Removing support for little used platforms
|
||||
Title: CPython platform support
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: Martin von Löwis <martin@v.loewis.de>,
|
||||
|
|
@ -14,76 +14,180 @@ Post-History: 18-Aug-2007,
|
|||
|
||||
|
||||
Abstract
|
||||
--------
|
||||
========
|
||||
|
||||
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
|
||||
---------
|
||||
=========
|
||||
|
||||
Over time, the CPython source code has collected various pieces of
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
platforms, it is not possible to determine whether a certain
|
||||
change to the CPython source code will work on all supported
|
||||
platforms.
|
||||
|
||||
To reduce this risk, this PEP specifies what is required for a
|
||||
platform to be considered supported by Python as well as providing a
|
||||
procedure to remove code for platforms with few or no Python
|
||||
platform to be considered supported by CPython as well as providing a
|
||||
procedure to remove code for platforms with few or no CPython
|
||||
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
|
||||
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).
|
||||
Support tiers
|
||||
=============
|
||||
|
||||
This policy does not disqualify supporting other platforms
|
||||
indirectly. Patches which are not platform-specific but still done to
|
||||
add platform support will be considered for inclusion. For example,
|
||||
if platform-independent changes were necessary in the configure
|
||||
script which were motivated to support a specific platform that could
|
||||
be accepted. Patches which add platform-specific code such as the
|
||||
name of a specific platform to the configure script will generally
|
||||
not be accepted without the platform having official support.
|
||||
Platform support is broken down into *tiers*. Each tier comes with
|
||||
different requirements which lead to different promises being made
|
||||
about support.
|
||||
|
||||
To be promoted to a tier, steering council support is required and is
|
||||
expected to be driven by team consensus. Demotion to a lower tier
|
||||
occurs when the requirements of the current tier are no longer met for
|
||||
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
|
||||
----------------------
|
||||
======================
|
||||
|
||||
If a certain platform that currently has special code in CPython is
|
||||
deemed to be without enough Python users or lacks proper support from
|
||||
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
|
||||
If a platform drops out of tiered support, a note must be posted
|
||||
in this PEP that the platform is no longer actively supported. This
|
||||
note must include:
|
||||
|
||||
- the name of the system
|
||||
|
|
@ -100,64 +204,14 @@ condition (usually a preprocessor symbol) that will become
|
|||
unsupported.
|
||||
|
||||
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 gives potential users of the platform a chance to step
|
||||
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
|
||||
-----------------------------
|
||||
=============================
|
||||
|
||||
* | Name: MS-DOS, MS-Windows 3.x
|
||||
| Unsupported in: Python 2.0
|
||||
|
|
@ -276,15 +330,15 @@ No-longer-supported platforms
|
|||
| Code removed in: Python 3.7
|
||||
|
||||
References
|
||||
----------
|
||||
==========
|
||||
|
||||
.. [1] http://support.microsoft.com/lifecycle/
|
||||
.. [2] http://buildbot.python.org/3.x.stable/
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue