PEP: 11 Title: CPython platform support Version: $Revision$ Last-Modified: $Date$ Author: Martin von Löwis , Brett Cannon Status: Active Type: Process Content-Type: text/x-rst Created: 07-Jul-2002 Post-History: `18-Aug-2007 `__, `14-May-2014 `__, `20-Feb-2015 `__, `10-Mar-2022 `__, Abstract ======== This PEP documents how an operating system (platform) becomes 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 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 CPython's evolution, or it may become unnecessary as the platforms evolve as well. 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 CPython as well as providing a procedure to remove code for platforms with few or no CPython users. 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. Support tiers ============= 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 ------ - `STATUS `__ - CI failures 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 ------ - `STATUS `__ - 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 Contacts ============================= ========================== ======== aarch64-apple-darwin clang Ned Deily, Ronald Oussoren, Dong-hee Na aarch64-unknown-linux-gnu glibc, gcc Petr Viktorin, Victor Stinner glibc, clang Victor Stinner, Gregory P. Smith powerpc64le-unknown-linux-gnu glibc, gcc Petr Viktorin, Victor Stinner x86_64-unknown-linux-gnu glibc, clang Victor Stinner, Gregory P. Smith ============================= ========================== ======== Tier 3 ------ - `STATUS `__ - 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 Contacts ================================ =========================== ======== aarch64-pc-windows-msvc Steve Dower powerpc64le-unknown-linux-gnu glibc, clang Victor Stinner s390x-unknown-linux-gnu glibc, gcc Victor Stinner x86_64-unknown-freebsd BSD libc, clang Victor Stinner armv7l-unknown-linux-gnueabihf Raspberry Pi OS, glibc, gcc 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". Unsupporting platforms ====================== 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 - the first release number that does not support this platform anymore, and - the first release where the historical support code is actively removed In some cases, it is not possible to identify the specific list of systems for which some code is used (e.g. when autoconf tests for absence of some feature which is considered present on all supported systems). In this case, the name will give the precise 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 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. No-longer-supported platforms ============================= * | Name: MS-DOS, MS-Windows 3.x | Unsupported in: Python 2.0 | Code removed in: Python 2.1 * | Name: SunOS 4 | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: DYNIX | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: dgux | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: Minix | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: Irix 4 and --with-sgi-dl | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: Linux 1 | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: Systems defining __d6_pthread_create (configure.in) | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: Systems defining PY_PTHREAD_D4, PY_PTHREAD_D6, or PY_PTHREAD_D7 in thread_pthread.h | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: Systems using --with-dl-dld | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: Systems using --without-universal-newlines, | Unsupported in: Python 2.3 | Code removed in: Python 2.4 * | Name: MacOS 9 | Unsupported in: Python 2.4 | Code removed in: Python 2.4 * | Name: Systems using --with-wctype-functions | Unsupported in: Python 2.6 | Code removed in: Python 2.6 * | Name: Win9x, WinME, NT4 | Unsupported in: Python 2.6 (warning in 2.5 installer) | Code removed in: Python 2.6 * | Name: AtheOS | Unsupported in: Python 2.6 (with "AtheOS" changed to "Syllable") | Build broken in: Python 2.7 (edit configure to re-enable) | Code removed in: Python 3.0 | Details: http://www.syllable.org/discussion.php?id=2320 * | Name: BeOS | Unsupported in: Python 2.6 (warning in configure) | Build broken in: Python 2.7 (edit configure to re-enable) | Code removed in: Python 3.0 * | Name: Systems using Mach C Threads | Unsupported in: Python 3.2 | Code removed in: Python 3.3 * | Name: SunOS lightweight processes (LWP) | Unsupported in: Python 3.2 | Code removed in: Python 3.3 * | Name: Systems using --with-pth (GNU pth threads) | Unsupported in: Python 3.2 | Code removed in: Python 3.3 * | Name: Systems using Irix threads | Unsupported in: Python 3.2 | Code removed in: Python 3.3 * | Name: OSF* systems (issue 8606) | Unsupported in: Python 3.2 | Code removed in: Python 3.3 * | Name: OS/2 (issue 16135) | Unsupported in: Python 3.3 | Code removed in: Python 3.4 * | Name: VMS (issue 16136) | Unsupported in: Python 3.3 | Code removed in: Python 3.4 * | Name: Windows 2000 | Unsupported in: Python 3.3 | Code removed in: Python 3.4 * | Name: Windows systems where COMSPEC points to command.com | Unsupported in: Python 3.3 | Code removed in: Python 3.4 * | Name: RISC OS | Unsupported in: Python 3.0 (some code actually removed) | Code removed in: Python 3.4 * | Name: IRIX | Unsupported in: Python 3.7 | Code removed in: Python 3.7 * | Name: Systems without multithreading support | Unsupported in: Python 3.7 | Code removed in: Python 3.7 Discussions =========== * April 2022: `Consider adding a Tier 3 to tiered platform support `_ (Victor Stinner) * March 2022: `Proposed tiered platform support `_ (Brett Cannon) * February 2015: `Update to PEP 11 to clarify garnering platform support `_ (Brett Cannon) * May 2014: `Where is our official policy of what platforms we do support? `_ (Brett Cannon) * August 2007: `PEP 11 update - Call for port maintainers to step forward `_ (Skip Montanaro) References ========== .. [1] http://support.microsoft.com/lifecycle/ Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: