Aktuelles Schema

Aus den Allgemeinen Python-FAQ: Wie funktioniert das Versionsnummerierungsschema von Python?

Python-Versionen werden als „A.B.C“ oder „A.B“ nummeriert.

• A ist die Hauptversionsnummer – sie wird nur für wirklich größere Änderungen an der Sprache erhöht.
• B ist die Nebenversionsnummer – sie wird für weniger weltbewegende Änderungen erhöht.
• C ist die Mikroversionsnummer – sie wird für jede Fehlerkorrekturveröffentlichung erhöht.

Python ist älter als SemVer

Semantic Versioning (SemVer) ist ein beliebtes Schema, das die Absicht einer Veröffentlichung kommunizieren soll (obwohl es nicht immer erfolgreich ist).

Gegeben eine Versionsnummer MAJOR.MINOR.PATCH, erhöhen Sie die

1. MAJOR-Version, wenn Sie inkompatible API-Änderungen vornehmen.
2. MINOR-Version, wenn Sie Funktionalität rückwärtskompatibel hinzufügen.
3. PATCH-Version, wenn Sie rückwärtskompatible Fehlerbehebungen vornehmen.

Leute gehen oft davon aus, dass Python SemVer folgt und beschweren sich über brachliegende Änderungen in Funktions- Veröffentlichungen. Aber Python ist SemVer um mindestens 15 Jahre voraus: die SemVer-Spezifikation wurde im Jahr 2009 eingeführt und das maßgeschneiderte Python-Schema wurde 1994 in die Quellcodeverwaltung aufgenommen für die Veröffentlichung 1.0.

Wenn Python SemVer annehmen würde, würde das bedeuten, dass jedes Jahr eine neue Hauptversion veröffentlicht wird, wenn wir Veralterungen entfernen.

Anstelle von SemVer haben jedoch einige Projekte ein anderes Versionsschema übernommen, das auf dem Kalender basiert.

Kalenderbasierte Versionierung

Mit Calendar Versioning (CalVer) integrieren Sie ein Element des Datums in die Versionsnummer. Zum Beispiel verwenden Ubuntu und Black das Jahr und den Monat – Ubuntu 24.04 kam im April 2024 heraus; pip und PyCharm verwenden nur das Jahr.

Und hier sind einige Programmiersprachenstandards, die alle eine Form des Jahres verwenden.

Jährlicher Veröffentlichungsrhythmus

Seit 2019 veröffentlichen wir jedes Jahr eine neue Version.

• 3.15.0 wird 2026 veröffentlicht.
• 3.16.0 wird 2027 veröffentlicht.
• 3.17.0 wird 2028 veröffentlicht.
• 3.18.0 wird 2029 veröffentlicht.
• 3.19.0 wird 2030 veröffentlicht.

Das ist eine Art kalenderbasiert, nur dass es um 11 Jahre versetzt ist.

CalVer für Python

Die einfachste CalVer-Option wäre, bei der Hauptversion 3 zu bleiben und das Jahr in der Nebenversion zu kodieren.

• 3.26.0 wird 2026 veröffentlicht.
• 3.27.0 wird 2027 veröffentlicht.
• 3.28.0 wird 2028 veröffentlicht.
• 3.29.0 wird 2029 veröffentlicht.
• 3.30.0 wird 2030 veröffentlicht.

Zum Beispiel wird 3.26 im Jahr 2026 veröffentlicht. Das macht offensichtlich, wann eine Veröffentlichung zum ersten Mal herauskam.

Klarheit bei der Entfernung von Veralterungen

Warnungen für Veralterungen erwähnen oft die Version, in der sie entfernt werden. Zum Beispiel:

DeprecationWarning: „ctypes.SetPointerType“ ist veraltet und soll in Python 3.15 entfernt werden.

Sobald man jedoch CalVer kennt, ist aus der Warnung sofort ersichtlich, wie viel Zeit man zum Handeln hat.

DeprecationWarning: „ctypes.SetPointerType“ ist veraltet und soll in Python 3.26 entfernt werden.

Klarheit des Support-Lebenszyklus

Momentan ist es etwas knifflig zu ermitteln, wann eine Veröffentlichung ihr End-of-Life hat. Zuerst muss man nachschauen, wann sie ursprünglich veröffentlicht wurde, und dann 5 Jahre hinzufügen.

„Wann wird Python 3.11 EOL sein?“

„Nun, mal sehen… PEP 664 ist der 3.11 Veröffentlichungsplan, er besagt, dass 3.11 2022 veröffentlicht wurde, EOL nach 5 Jahren, also 2022 + 5 = 2027.“

Aber wenn das Jahr der Erstveröffentlichung direkt in der Version steht, ist es viel einfacher.

„Wann wird Python 3.26 EOL sein?“

„26 + 5 = [20]31“

Klarheit des Installationsalters

Mit dem Jahr in der Version ist es einfacher zu ermitteln, wie alt die Installation ist. Zum Beispiel ist es mit dem aktuellen Schema, wenn Sie 2035 Python 3.15 verwenden, nicht sofort ersichtlich, dass es 2026 erstmals veröffentlicht wurde (und seit 2031 EOL ist).

Mit Kenntnis von CalVer ist es klar, wenn Sie 2035 Python 3.26 verwenden, dass es vor neun Jahren zum ersten Mal veröffentlicht wurde und es wahrscheinlich Zeit für ein Upgrade ist.

Dies kann dazu beitragen, Leute zum Wechsel zu unterstützten Versionen zu bewegen, die noch unter Sicherheitsunterstützung stehen, und neuen Benutzern helfen, die möglicherweise ältere Installationen haben.

Klarheit der Versionsunterstützung

CalVer macht es einfacher, darüber nachzudenken, welche Python-Versionen unterstützt werden sollen.

Zum Beispiel setzt die Festlegung Ihrer minimalen kompatiblen Python-Version auf 3.19 im Jahr 2031 ohne CalVer eine aggressive Annahme hinsichtlich der Versionsübernahme und -unterstützung.

Mit CalVer ist dies jedoch offensichtlicher, wenn die Mindestversion 3.30 im Jahr 2031 festgelegt wird. Für breitere Unterstützung bevorzugen Sie vielleicht die Festlegung auf 3.26.

Ähnlich müssen Bibliothekspfleger, die alle CPython-Upstream-Versionen unterstützen, gegen fünf Versionen (oder sechs einschließlich der Vorabversion) testen.

Zum Beispiel wären im Jahr 2030 die unterstützten Versionen ohne CalVer

• 3.15, 3.16, 3.17, 3.18, 3.19

Mit CalVer wären sie

• 3.26, 3.27, 3.28, 3.29, 3.30

Ein Betreuer kann auf einen Blick sehen, welche Versionen aktuell sind und getestet werden müssen.

Non-goals

Wie beim aktuellen Schema wird nur die Mikroversion für Fehlerbehebungs- und Sicherheitsveröffentlichungen erhöht, ohne Änderung an Haupt- und Nebenversion. Zum Beispiel:

Keine Änderung an PEP 602 (Jährlicher Veröffentlichungszyklus für Python).

• Keine Änderung an den 17 Monaten zur Entwicklung einer neuen Funktion: Alphas, Betas und Release Candidates.
• Keine Änderung an der Support-Dauer: zwei Jahre voller Support und drei Jahre Sicherheitsupdates.
• Keine Änderung am jährlichen Oktober-Veröffentlichungsrhythmus.

JJ.0

Zum Beispiel würde Python 26.0 im Jahr 2026 veröffentlicht werden.

Es gibt nicht viel Interesse an Python Version 4. Wir wollen nicht 2 zu 3 wiederholen, und 4 weckt inzwischen hohe Erwartungen. Wir wollen keine „weltbewegenden Änderungen“.

Vielleicht könnte Python 4 für etwas Großes wie die Entfernung des GIL (PEP 703) reserviert werden, aber der Steering Council hat klargestellt, dass die Rollout von Free-Threading schrittweise erfolgen muss. Werden wir ewig bei Version 3 bleiben?

Eine andere Option wäre, die Jahreszahl in die Hauptversion zu setzen und zu 26.0 zu springen. Das könnte bedeuten, dass wir all die 4.0-Altlasten überspringen könnten.

'this is Python {}'.format(sys.version[:5])

".%s-%s" % (get_platform(), sys.version[0:3])

if sys.version_info[1] >= 9:

if sys.version[0] == '3':

JJ.MM

Zum Beispiel würde Python 26.10 im Oktober 2026 veröffentlicht.

Aufbauend auf der JJ.0-Versionierung könnten wir auch den Veröffentlichungsmonat als Nebenversion einbeziehen, ähnlich wie bei Ubuntu und Black. Dies würde klarstellen, *wann* im Jahr die Version veröffentlicht wurde, und auch, *wann* im Jahr sie ihr End-of-Life erreicht.

Jedoch wird die JJ.MM-Versionierung aus vielen der gleichen Gründe wie die JJ.0-Versionierung abgelehnt.

3.JJJJ

Zum Beispiel würde Python 3.2026 im Jahr 2026 veröffentlicht.

Es ist klarer, dass die Nebenversion eine Jahreszahl ist, wenn eine vierstellige verwendet wird, und vermeidet Verwechslungen mit Ubuntu-Versionen, die JJ.MM verwenden.

Editionen

Zum Beispiel würde Python 3.15 (2026 Edition) im Jahr 2026 veröffentlicht.

Die Programmiersprache Rust verwendet „Editions“, um Breaking Changes einzuführen. Die Anwendung dessen auf Python würde große Änderungen an PEP 387 (Richtlinie zur Abwärtskompatibilität) erfordern und liegt außerhalb des Rahmens dieses PEP.

Wir könnten den Veröffentlichungen eine Jahresbezeichnung zuweisen, wie z. B. „Python 3.15 (2026 Edition)“, aber dies wird abgelehnt, da wir *zwei* Zahlen verfolgen müssten.

SemVer übernehmen und 4 überspringen

Zum Beispiel würde Python 5.0 im Jahr 2026 veröffentlicht, 6.0 im Jahr 2027 und so weiter.

Wir könnten die problematische 4.0 komplett überspringen und SemVer übernehmen. Da Veralterungen in jeder Feature-Veröffentlichung entfernt werden, würden wir jedes Jahr einen neuen Hauptversionssprung erhalten.

Dies wird abgelehnt, da wir nicht den Vorteil der kalenderbasierten Versionierung erhalten würden und eine Abkehr von 3.x ebenfalls Code brechen würde.

Änderung während des 3.14-Zyklus

Die Veröffentlichung von Python 3.14 muss fortgesetzt werden, da: π.

Versionszuordnung

Die Versionen 3.15 bis einschließlich 3.25 werden übersprungen. Geplante Features, Veralterungen und Entfernungen für diese werden auf die neuen Versionsnummern umgemappt.

Zum Beispiel wird eine Veralterung, die ursprünglich für die Entfernung in 3.16 geplant war, stattdessen in 3.27 entfernt.

Zukünftige Änderung des Rhythmus

Dieser PEP schlägt keine Änderung des jährlichen Veröffentlichungszyklus gemäß PEP 602 vor, der viele gute Gründe für jährliche Veröffentlichungen (z. B. kleinere Veröffentlichungen mit einem vorhersehbaren Veröffentlichungskalender und Synchronisation mit externen Redundanten) darlegt. Wie unwahrscheinlich es auch sein mag, falls wir uns entscheiden, den Rhythmus in Zukunft zu ändern, CalVer schließt dies nicht aus.

Kein CalVer mehr

Die Übernahme von CalVer schließt nicht aus, sich in Zukunft von CalVer zu trennen, z. B. zurück zum ursprünglichen Schema, zu SemVer oder einem anderen Schema. Einige Optionen sind in der obigen Tabelle aufgeführt. Wenn man klarstellen möchte, dass die Nebenversion nicht mehr das Jahr ist, kann sie auf eine höhere runde Zahl (z. B. 3.50 oder 3.100) erhöht oder die Hauptversion erhöht werden (z. B. auf 4.0 oder 5.0). Zusätzlich könnte ein Versions-Epoch in Betracht gezogen werden.