Release-Zyklus

Wenn Wartungs-Releases erstellt werden, werden *zwei* neue Versionen von Python tatsächlich auf python.org veröffentlicht (am Beispiel des ersten 3.3-Wartungs-Releases, geplant für Februar 2013):

3.3.1       # Maintenance release
3.3 (33.1)  # Standard library release

Weitere 6 Monate später wird das nächste 3.3-Wartungs-Release erneut von einem neuen Standard Library Release begleitet.

3.3.2       # Maintenance release
3.3 (33.2)  # Standard library release

Auch hier ist das Standard Library Release binärkompatibel mit dem vorherigen Sprach-Release und bietet lediglich zusätzliche Funktionen auf Python-Ebene.

Schließlich, 18 Monate nach der Veröffentlichung von 3.3, wird ein neues Sprach-Release ungefähr zur gleichen Zeit wie die letzten 3.3-Wartungs- und Standard Library Releases veröffentlicht.

3.3.3       # Maintenance release
3.3 (33.3)  # Standard library release
3.4.0       # Language release

Der 3.4 Release-Zyklus würde dann einem ähnlichen Muster wie der für 3.3 folgen.

3.4.1       # Maintenance release
3.4 (34.1)  # Standard library release

3.4.2       # Maintenance release
3.4 (34.2)  # Standard library release

3.4.3       # Maintenance release
3.4 (34.3)  # Standard library release
3.5.0       # Language release

Programmatische Versionsidentifizierung

Um die neuen Versionsdetails programmatisch verfügbar zu machen, schlägt dieser PEP die Ergänzung eines neuen sys.stdlib_info-Attributs vor, das die neue Standardbibliothek-Version zusätzlich zur zugrundeliegenden Interpreter-Version speichert. Am Beispiel des ersten Python 3.3-Releases:

sys.stdlib_info(python=33, version=0, releaselevel='final', serial=0)

Diese Informationen würden auch in den sys.version-String aufgenommen werden.

Python 3.3.0 (33.0, default, Feb 17 2012, 23:03:41)
[GCC 4.6.1]

Sicherheitskorrekturen und andere „Außerhalb des Zyklus“-Releases

Für Wartungs-Releases bleibt der Prozess der Behandlung von Releases außerhalb des Zyklus (z. B. zur Behebung eines Sicherheitsproblems oder eines kritischen Fehlers in einem neuen Release) derselbe wie jetzt: Die Nebenversionsnummer wird erhöht und ein neues Release erstellt, das die erforderlichen Fehlerbehebungen sowie alle anderen seit dem vorherigen Release committeden Fehlerbehebungen enthält.

Für Standard Library Releases ist der Prozess im Wesentlichen derselbe, aber das entsprechende „Was gibt es Neues?“-Dokument muss möglicherweise etwas aufgeräumt werden (da das Standard Library Release neue Funktionen enthalten kann, nicht nur Fehlerbehebungen).

Anfänger, der Python im März 2013 von python.org herunterlädt

Status quo: muss zwischen 3.3 und 2.7 wählen

Dieser PEP: muss zwischen 3.3 (33.1), 3.3 und 2.7 wählen.

PEP 407: muss zwischen 3.4, 3.3 (LTS) und 2.7 wählen.

Urteil: Die Erklärung der Bedeutung einer Long-Term-Support-Version ist ungefähr so kompliziert wie die Erklärung der Bedeutung der vorgeschlagenen Versionsnummern der Standardbibliothek. Ich nenne das ein Unentschieden.

Anfänger, der versucht, das Alter von Drittanbieter-Dokumentationen zu beurteilen

Status quo: Minor-Versionsunterschiede deuten auf 18-24 Monate Sprachentwicklung hin

Dieser PEP: wie Status quo für den Sprachkern, Versionsnummern der Standardbibliothek deuten auf 6 Monate Standardbibliothek-Entwicklung hin.

PEP 407: Minor-Versionsunterschiede deuten auf 18-24 Monate Sprachentwicklung bis 3.3, danach 6 Monate Sprachentwicklung.

Urteil: Da Sprachänderungen und Stilllegungen einen viel größeren Einfluss auf die Genauigkeit von Drittanbieter-Dokumentationen haben können als die Hinzufügung neuer Funktionen zur Standardbibliothek, bewerte ich dies als einen Sieg für das Schema in diesem PEP.

Anfänger, der nach einer binären Veröffentlichung eines Erweiterungsmoduls sucht

Status quo: suchen Sie nach der Binärdatei, die der laufenden Python-Version entspricht.

Dieser PEP: wie Status quo.

PEP 407 (vollständige Releases): wie Status quo, aber die entsprechende Binärdatei fehlt mit größerer Wahrscheinlichkeit (oder muss, wenn sie existiert, aus einer viel größeren Liste von Alternativen gefunden werden).

PEP 407 (ABI-Updates nur für LTS-Releases): Alle Binärdatei-Release-Seiten müssen den Benutzern mitteilen, dass Python 3.3, 3.4 und 3.5 alle die 3.3-Binärdatei benötigen.

Urteil: Ich bewerte dies als klaren Sieg für das Schema in diesem PEP. Absolut nichts ändert sich gegenüber der aktuellen Situation, da die Standardbibliothek-Version in diesem Fall tatsächlich irrelevant ist (nur die Kompatibilität binärer Erweiterungen ist wichtig).

Autor eines Erweiterungsmoduls, der entscheidet, ob er eine binäre Veröffentlichung machen soll oder nicht

Status quo: Wenn nicht bereits vorhanden, ist eine neue Binärdatei erforderlich, jedes Mal, wenn sich die Nebenversionsnummer ändert (außer bei Verwendung der PEP 384 stabilen ABI).

Dieser PEP: wie Status quo.

PEP 407 (vollständige Releases): wie Status quo, wird aber zu einem weitaus häufigeren Ereignis.

PEP 407 (ABI-Updates nur für LTS-Releases): Vor der Entscheidung muss zuerst nachgeschlagen werden, ob das neue Release ein LTS-Release oder ein Interim-Release ist. Wenn es ein LTS-Release ist, ist ein neuer Build erforderlich.

Urteil: Ich bewerte dies als einen weiteren klaren Sieg für das Schema in diesem PEP. Wie auf der Endbenutzerseite dieses Problems ist die Standardbibliothek-Version in diesem Fall tatsächlich irrelevant. Das Auslagern dieser Informationen in eine separate Nummer vermeidet unnötige Verwirrung.

Python-Entwickler, der die Priorität der Beseitigung einer Deprecation Warning bestimmt

Status quo: Code, der Warnungen vor veralteten Funktionen auslöst, wird nicht garantiert auf einer Python-Version mit einer höheren Nebenversionsnummer ausgeführt.

Dieser PEP: wie Status quo

PEP 407: unklar, da der PEP dies derzeit nicht spezifiziert. Unter der Annahme, dass der Stilllegungszyklus an LTS-Releases gekoppelt ist, ist das Upgrade auf ein Nicht-LTS-Release sicher, aber das Upgrade auf das nächste LTS-Release erfordert möglicherweise die Vermeidung der veralteten Konstruktion.

Urteil: Ein weiterer klarer Sieg für das Schema in diesem PEP, da die Standardbibliothek-Version in diesem Szenario erneut irrelevant ist.

Implementierer eines alternativen Interpreters, der mit neuen Funktionen aktualisiert

Status quo: neue Python-Versionen erscheinen selten, sind aber ein Sammelsurium aus Standardbibliothek-Updates und Änderungen an der Kernsprache und dem Interpreter.

Dieser PEP: Standardbibliothek-Updates, die einfacher zu integrieren sind, werden häufiger in einer Form bereitgestellt, die klar und explizit mit der vorherigen Version der Sprachdefinition kompatibel ist. Das bedeutet, dass alternative Implementierungen, sobald sie Python 3.3 erreicht haben, die Integration von Standardbibliotheksfunktionen, wie sie auftreten, (insbesondere rein Python-Änderungen) deutlich einfacher haben sollten, sodass nur noch die Minor-Version-Updates als einzige Aufgabe verbleiben, die die Aktualisierung ihrer Kernkompilierungs- und Ausführungskomponenten erfordert.

PEP 407 (vollständige Releases): wie Status quo, wird aber zu einem weitaus häufigeren Ereignis.

PEP 407 (Sprachupdates nur für LTS-Releases): unklar, da der PEP derzeit keine spezifische Entwicklungsstrategie festlegt. Unter der Annahme, dass ein 3.3-Kompatibilitätszweig übernommen wird (wie in diesem PEP vorgeschlagen), wäre das Ergebnis weitgehend dasselbe, aber die Versionsnummern-Signalgebung wäre etwas weniger klar (da man prüfen müsste, ob ein bestimmtes Release ein LTS-Release ist oder nicht).

Urteil: Obwohl nicht so eindeutig wie einige frühere Szenarien, bewerte ich dies immer noch zugunsten des Schemas in diesem PEP. Explizit ist besser als implizit, und das Schema in diesem PEP trennt klar zwischen den beiden verschiedenen Arten von Updates, anstatt eine separate „LTS“-Kennzeichnung zu einer ansonsten gewöhnlichen Release-Nummer hinzuzufügen. Das Kennzeichnen einer bestimmten Version als besonders ist großartig für die Kommunikation mit Versionskontrollsystemen und zugehörigen automatisierten Tools, aber eine schlechte Möglichkeit, Informationen an andere Menschen zu übermitteln.

Python-Entwickler, der seine minimale Versionsabhängigkeit festlegt

Status quo: Suchen Sie nach Markierungen „Version hinzugefügt“ oder „Version geändert“ in der Dokumentation, vergleichen Sie mit sys.version_info

Dieser PEP: Suchen Sie nach Markierungen „Version hinzugefügt“ oder „Version geändert“ in der Dokumentation. Wenn als reine Python-Version geschrieben, wie z. B. „3.3“, vergleichen Sie mit sys.version_info. Wenn mit einer Standardbibliothek-Version qualifiziert, wie z. B. „3.3 (33.1)“, vergleichen Sie mit sys.stdlib_info.

PEP 407: wie Status quo

Urteil: Das Schema in diesem PEP ermöglicht es Drittanbieterbibliotheken tatsächlich, expliziter über ihre Übernahme von Standardbibliotheksfunktionen zu informieren. Konservativere Projekte werden ihre Abhängigkeit wahrscheinlich an die Sprachversion binden und Funktionen vermeiden, die in den Standardbibliothek-Releases hinzugefügt wurden. Schnellere Projekte könnten stattdessen ihre Abhängigkeit von einer bestimmten Standardbibliothek-Version deklarieren. Da PEP 407 jedoch den Vorteil hat, den Status quo beizubehalten, bewerte ich dies für PEP 407 (wenn auch mit knapper Mehrheit).

Python-Entwickler, die versuchen, ein Tracker-Problem zu reproduzieren

Status quo: Wenn nicht bereits vorhanden, fragen Sie den Melder, welche Python-Version er verwendet. Dies geschieht oft, indem nach den ersten beiden Zeilen gefragt wird, die die interaktive Eingabeaufforderung anzeigt, oder nach dem Wert von sys.version.

Dieser PEP: wie der Status quo (da sys.version aktualisiert wird, um auch die Standardbibliothek-Version zu enthalten), kann aber in zusätzlichen Fällen erforderlich sein (wenn der Benutzer genug wusste, um seine Python-Version anzugeben, diese aber nicht ausreichte, um den Fehler zu reproduzieren).

PEP 407: wie der Status quo

Urteil: Ein weiterer geringfügiger Vorteil für PEP 407. Die neue Standardbibliothek-Version *ist* eine zusätzliche Information, die Benutzer möglicherweise an Entwickler zurückgeben müssen, wenn sie Probleme mit Python-Bibliotheken (oder Python selbst auf unserem eigenen Tracker) melden. Da sie jedoch in sys.version enthalten ist, enthalten viele Fehlerberichte sie bereits, und sie ist leicht anzufordern, wenn nötig.

CPython-Release-Manager, die sich mit einer Sicherheitskorrektur befassen

Status quo: Erstellen Sie ein neues Wartungs-Release, das die Sicherheitskorrektur und alle anderen Fehlerbehebungen unter Quellcodeverwaltung enthält. Erstellen Sie auch Quellcode-Releases für alle Zweige, die nur für Sicherheitskorrekturen geöffnet sind.

Dieser PEP: wie der Status quo für Wartungszweige. Erstellen Sie auch ein neues Standard Library Release (potenziell mit neuen Funktionen zusätzlich zur Sicherheitskorrektur). Für Sicherheitszweige erstellen Sie Quellcode-Releases sowohl für den ehemaligen Wartungszweig als auch für den Standardbibliothek-Update-Zweig.

PEP 407: wie der Status quo für Wartungs- und Sicherheitszweige, aber die Behandlung von Sicherheitskorrekturen für Nicht-LTS-Releases ist derzeit eine offene Frage.

Urteil: Bis PEP 407 aktualisiert wird, um dieses Szenario tatsächlich zu behandeln, ein klarer Sieg für diesen PEP.

Auswirkung auf den Entwicklungszyklus

Ähnlich wie PEP 407 wird dieser PEP die Bereitstellung neuer Funktionen in diskretere Blöcke aufteilen. Anstatt einer ganzen Reihe von Änderungen, die auf einmal in einem Sprach-Release landen, wird jedes Sprach-Release auf 6 Monate an Standardbibliotheksänderungen sowie auf alle Änderungen beschränkt sein, die mit neuer Syntax verbunden sind.

Auswirkung auf den Workflow

Dieser PEP schlägt die Erstellung eines einzigen zusätzlichen Zweigs für die Verwendung im normalen Workflow vor. Nach der Veröffentlichung von 3.3 würden die folgenden Zweige verwendet werden:

2.7         # Maintenance branch, no change
3.3         # Maintenance branch, as for 3.2
3.3-compat  # New branch, backwards compatible changes
default     # Language changes, standard library updates that depend on them

Bei der Arbeit an einer neuen Funktion müssen die Entwickler entscheiden, ob es sich um eine akzeptable Änderung für ein Standard Library Release handelt oder nicht. Wenn ja, sollte sie auf 3.3-compat eingecheckt und dann nach default zusammengeführt werden. Andernfalls sollte sie direkt in default eingecheckt werden.

Die Markierungen „Version hinzugefügt“ und „Version geändert“ für Änderungen, die auf dem 3.3-compat-Zweig vorgenommen wurden, müssen sowohl mit der Sprachversion als auch mit der Standardbibliothek-Version gekennzeichnet werden. Zum Beispiel: „3.3 (33.1)“.

Änderungen, die direkt auf dem default-Zweig vorgenommen werden, werden wie üblich nur mit „3.4“ gekennzeichnet.

Der 3.3-compat-Zweig wird gleichzeitig mit dem 3.3-Wartungszweig für die normale Entwicklung geschlossen. Der 3.3-compat-Zweig bleibt für Sicherheitskorrekturen für den gleichen Zeitraum offen wie der 3.3-Wartungszweig.

Auswirkung auf den Bugfix-Zyklus

Die Auswirkung auf den Bugfix-Workflow ist im Wesentlichen dieselbe wie auf den Workflow für neue Funktionen – es gibt einen zusätzlichen Zweig, der durchlaufen werden muss, bevor die Änderung den default-Zweig erreicht.

Wenn kritische Fehler in einem Wartungs-Release gefunden werden, werden neue Wartungs- und Standard Library Releases erstellt, um das Problem zu beheben. Der letzte Teil der Versionsnummer wird sowohl für die Sprachversion als auch für die Standardbibliothek-Version erhöht.

Wenn kritische Fehler in einem Standard Library Release gefunden werden, die das zugehörige Wartungs-Release nicht beeinträchtigen, wird nur ein neues Standard Library Release erstellt und nur die Versionsnummer der Standardbibliothek erhöht.

Beachten Sie, dass unter diesen Umständen das Standard Library Release möglicherweise zusätzliche Funktionen *enthält* und nicht nur den Fehlerbehebung. Es wird davon ausgegangen, dass jeder, dem es wichtig ist, *nur* Fehlerbehebungen ohne neue Funktionen zu erhalten, bereits strikt auf die Wartungs-Releases angewiesen ist und die neuen Standard Library Releases nicht verwendet.

Auswirkung auf die Community

PEP 407 sagt Folgendes über die Auswirkungen auf die Community:

Leute, die Stabilität schätzen, können sich einfach an die LTS-Releases halten, die mit den vorgeschlagenen Zahlen einen ähnlichen Support-Zyklus (sowohl in Dauer als auch in Stabilität) bieten.

Ich glaube, diese Aussage ist schlichtweg falsch. Das Leben ist nicht so einfach. Stattdessen geraten Entwickler von Drittanbieter-Modulen und -Frameworks unter Druck, den vollen Takt des neuen Release-Zyklus mit Binär-Updates zu unterstützen, Lehrer und Buchautoren erhalten Beschwerden, dass sie nur eine „alte“ Version von Python behandeln („Sie verwenden nur 3.3, die neueste ist 3.5!“), usw.

Da die Nebenversionsnummer 3-mal schneller ansteigt als bisher, würde meiner Meinung nach die Wahrnehmung der Sprachstabilität sinken (unabhängig davon, ob solche Meinungen gerechtfertigt waren oder nicht).

Ich glaube, dass die Isolierung des erhöhten Innovationstempos auf die Standardbibliothek und deren klare Abgrenzung durch eine separate Versionsnummer die übrige Community stark beruhigen wird, dass wir sie nicht plötzlich auffordern, ihre eigene Entwicklungsrate zu verdreifachen. Stattdessen werden wir lediglich Standardbibliotheks-Updates für das nächste Sprach-Release in 6-monatigen Intervallen ausliefern, anstatt sie alle bis zum nächsten Update der Sprachdefinition zu verzögern, selbst wenn es sich um Änderungen handelt, die abwärtskompatibel mit der zuvor veröffentlichten Python-Version sind.

Die in PEP 407 aufgeführten Community-Vorteile gelten gleichermaßen für diesen PEP, zumindest was die Standardbibliothek betrifft:

Leute, die Reaktivität und Zugang zu neuen Funktionen schätzen (ohne das Risiko einzugehen, Alpha-Versionen oder Mercurial-Snapshots zu installieren), würden erheblich mehr Wert aus dem neuen Release-Zyklus ziehen als derzeit.

Leute, die neue Funktionen oder Verbesserungen beitragen möchten, wären motivierter, dies zu tun, da sie wissen, dass ihre Beiträge schneller für normale Benutzer verfügbar sein werden.

Wenn der schnellere Release-Zyklus mehr Leute dazu ermutigt, sich auf die Beiträge zur Standardbibliothek zu konzentrieren, anstatt Änderungen an der Sprachdefinition vorzuschlagen, sehe ich das nicht als schlechte Sache.

Was gibt es Neues?

Die „Was gibt es Neues?“-Dokumente würden in separate Dokumente für Standard Library Releases und Sprach-Releases aufgeteilt. Während des 3.3 Release-Zyklus würden wir also sehen:

• Was gibt es Neues in Python 3.3?
• Was gibt es Neues in der Python-Standardbibliothek 33.1?
• Was gibt es Neues in der Python-Standardbibliothek 33.2?
• Was gibt es Neues in der Python-Standardbibliothek 33.3?

Und dann schließlich würden wir das nächste Sprach-Release sehen:

• Was gibt es Neues in Python 3.4?

Zum Nutzen von Benutzern, die Standard Library Releases ignorieren, würde das „Was gibt es Neues?“-Dokument für 3.4 auf die „Was gibt es Neues?“-Dokumente für jedes der Standard Library Releases der 3.3-Serie verlinken.

NEWS

Merge-Konflikte in der NEWS-Datei sind bereits ein Ärgernis. Da dieser PEP die Einführung eines zusätzlichen Zweigs in den normalen Workflow vorschlägt, wird die Lösung dieses Problems noch kritischer. Während Mercurial-Phasen bis zu einem gewissen Grad helfen können, wäre es gut, das Problem vollständig zu beseitigen.

Ein Vorschlag von Barry Warsaw ist die Einführung eines nicht-konfliktbehafteten Ansatzes mit separaten Dateien pro Änderung, ähnlich dem, was von Twisted verwendet wird [2].

Da die aktuelle manuell aktualisierte NEWS-Datei für das 3.3.0-Release verwendet wird, könnte ein mögliches Layout für einen solchen Ansatz so aussehen:

Misc/
  NEWS  # Now autogenerated from news_entries
  news_entries/
    3.3/
      NEWS # Original 3.3 NEWS file
      maint.1/ # Maintenance branch changes
        core/
          <news entries>
        builtins/
          <news entries>
        extensions/
          <news entries>
        library/
          <news entries>
        documentation/
          <news entries>
        tests/
          <news entries>
      compat.1/ # Compatibility branch changes
        builtins/
          <news entries>
        extensions/
          <news entries>
        library/
          <news entries>
        documentation/
          <news entries>
        tests/
          <news entries>
      # Add maint.2, compat.2 etc as releases are made
    3.4/
      core/
        <news entries>
      builtins/
        <news entries>
      extensions/
        <news entries>
      library/
        <news entries>
      documentation/
        <news entries>
      tests/
        <news entries>
      # Add maint.1, compat.1 etc as releases are made

Das Platzieren der Versionsinformationen in der Verzeichnisstruktur ist nicht unbedingt erforderlich (da der NEWS-Dateigenerator dies aus dem Versionsverlauf ermitteln könnte), erleichtert aber *Menschen* das Ordnen der verschiedenen Versionen.

Verlangsamung des Sprach-Release-Zyklus

Der aktuelle Release-Zyklus ist ein Kompromiss zwischen dem Wunsch nach Stabilität in der Kernsprache und der C-Erweiterungs-ABI und dem Wunsch, neue Funktionen (insbesondere Standardbibliothek-Updates) schneller in die Hände der Benutzer zu bringen.

Mit dem (bis zu einem gewissen Grad) entkoppelten Release-Zyklus der Standardbibliothek von dem der Kernsprache bietet sich die Gelegenheit, die Änderungsrate der Sprache tatsächlich zu *verlangsamen*. Das Sprachmoratorium für Python 3.2 hat diesen Zyklus effektiv auf *mehr als 3 Jahre* verlangsamt (3.1: Juni 2009, 3.3: August 2012), ohne größere Probleme oder Beschwerden zu verursachen.

Das oben beschriebene NEWS-Dateiverwaltungsschema ist tatsächlich darauf ausgelegt, uns die Flexibilität zu geben, Sprach-Releases zu verlangsamen, während Standardbibliothek-Releases häufiger werden.

Als einfaches Beispiel: Wenn zwischen 3.3 und 3.4 volle zwei Jahre gewartet würden, würde der 3.3 Release-Zyklus folgendermaßen aussehen:

3.2.4       # Maintenance release
3.3.0       # Language release

3.3.1       # Maintenance release
3.3 (33.1)  # Standard library release

3.3.2       # Maintenance release
3.3 (33.2)  # Standard library release

3.3.3       # Maintenance release
3.3 (33.3)  # Standard library release

3.3.4       # Maintenance release
3.3 (33.4)  # Standard library release
3.4.0       # Language release

Die Eleganz der vorgeschlagenen Verzweigungsstruktur und des Layouts des NEWS-Eintrags besteht darin, dass diese Entscheidung erst kurz vor dem geplanten Release-Datum von 3.4 getroffen werden müsste. Zu diesem Zeitpunkt könnte beschlossen werden, das Release 3.4 zu verschieben und die Verzweigungen 3.3 und 3.3-compat nach dem Wartungs-Release 3.3.3 und dem Standardbibliotheks-Release 3.3 (33.3) offen zu halten, wodurch der Zyklus um ein weiteres Standardbibliotheks-Release erweitert würde. Die Wahl zwischen einer weiteren Standardbibliotheks-Veröffentlichung oder einer vollständigen Sprachveröffentlichung wäre danach alle 6 Monate verfügbar.

Weitere Beschleunigung der Entwicklung der Standardbibliothek

Wie im vorherigen Abschnitt erwähnt, besteht ein Vorteil des in diesem PEP vorgeschlagenen Schemas darin, dass es den Release-Zyklus der Sprache weitgehend vom Release-Zyklus der Standardbibliothek entkoppelt. Die Standardbibliothek könnte alle 3 Monate oder sogar einmal im Monat aktualisiert werden, ohne Auswirkungen auf die Versionsnummerierung der Sprache oder die wahrgenommene Stabilität der Kernsprache zu haben.

Während dieses Entwicklungstempo so lange unpraktisch ist, wie die Erstellung von binären Installationsprogrammen für Windows und Mac OS X mehrere manuelle Schritte (einschließlich manueller Tests) beinhaltet und solange wir keine separaten "<branch>-release"-Bäume haben, die nur Versionen erhalten, die von den stabilen Buildbots als gut befunden wurden, ist dies immer noch ein nützliches Kriterium, das bei der Betrachtung vorgeschlagener neuer Versionsschemata zu beachten ist: Was wäre, wenn wir irgendwann Standardbibliotheks-Releases sogar noch *schneller* als alle 6 Monate machen wollen?

Wenn die praktischen Probleme jemals gelöst würden, dann könnte das separate Versionsschema der Standardbibliothek in diesem PEP damit umgehen. Der im PEP 407 vorgeschlagene Ansatz mit der getaggten Versionsnummer könnte dies nicht (zumindest nicht ohne große Verwirrung und Unsicherheit für die Benutzer).

Warum nicht die Hauptversionsnummer verwenden?

Die einfachste und logischste Lösung wäre tatsächlich, die Major.Minor.Micro-Versionsnummern entsprechend der Sprachversion, der Standardbibliotheksversion und der Wartungs-Release-Version abzubilden.

Anstatt Python 3.3.0 zu veröffentlichen, würden wir stattdessen Python 4.0.0 veröffentlichen und der Release-Zyklus würde so aussehen

4.0.0  # Language release

4.0.1  # Maintenance release
4.1.0  # Standard library release

4.0.2  # Maintenance release
4.2.0  # Standard library release

4.0.3  # Maintenance release
4.3.0  # Standard library release
5.0.0  # Language release

Der anhaltende Schmerz des Übergangs von Python 2 zu Python 3 (und damit verbundene Workarounds wie die Symlinks python3 und python2, um direkt auf die gewünschte Release-Serie zu verweisen) bedeutet jedoch, dass diese einfache Option aus historischen Gründen nicht praktikabel ist.

Eine Möglichkeit, wie dieser einfache Ansatz *funktionieren* könnte, ist die Zusammenführung der aktuellen Major- und Minor-Versionsnummern direkt in eine 2-stellige Major-Versionsnummer

33.0.0  # Language release

33.0.1  # Maintenance release
33.1.0  # Standard library release

33.0.2  # Maintenance release
33.2.0  # Standard library release

33.0.3  # Maintenance release
33.3.0  # Standard library release
34.0.0  # Language release

Warum nicht eine vierstellige Versionsnummer verwenden?

Ein weiteres einfaches Versionsschema würde dem bestehenden Versionsschema einfach eine "Standardbibliothek"-Version hinzufügen

3.3.0.0  # Language release

3.3.0.1  # Maintenance release
3.3.1.0  # Standard library release

3.3.0.2  # Maintenance release
3.3.2.0  # Standard library release

3.3.0.3  # Maintenance release
3.3.3.0  # Standard library release
3.4.0.0  # Language release

Dieses Schema ist jedoch aufgrund von Kompatibilitätsbeschränkungen für die Rückwärtskompatibilität der sys.version_info-Struktur nicht praktikabel.

Warum kein datumsbasiertes Versionsschema?

Frühere Versionen dieses PEP schlugen ein datumsbasiertes Versionsschema für die Standardbibliothek vor. Ein solches Schema machte es jedoch sehr schwierig, Out-of-Cycle-Releases zur Behebung von Sicherheitsproblemen und anderen kritischen Fehlern in Standardbibliotheks-Releases zu handhaben, da es die folgenden Schritte erforderte:

1. Ändern Sie die Release-Versionsnummer auf das Datum des aktuellen Monats.
2. Aktualisieren Sie "What's New", "NEWS" und die Dokumentation, um auf die neue Release-Nummer zu verweisen.
3. Machen Sie das neue Release.

Mit dem nun vorgeschlagenen sequentiellen Schema sollten solche Releases höchstens eine geringfügige Bereinigung des "What's New"-Dokuments erfordern, bevor das Release erstellt wird.

Warum ist PEP 384 nicht ausreichend?

PEP 384 führte den Begriff "Stable ABI" (stabile Anwendungsprogrammierschnittstelle) für CPython ein, eine begrenzte Teilmenge der vollständigen C-ABI, die garantiert stabil bleibt. Erweiterungen, die gegen die stabile ABI erstellt wurden, sollten alle nachfolgenden Python-Versionen mit derselben Binärdatei unterstützen können.

Dies wird neuen Projekten helfen, die zu enge Kopplung ihrer C-Erweiterungsmodule an eine bestimmte Version von CPython zu vermeiden. Für bestehende Module kann die Migration zur stabilen ABI jedoch recht viel Arbeit bedeuten (insbesondere für Erweiterungsmodule, die viele Klassen definieren). Bei begrenzten verfügbaren Entwicklungsressourcen ist jede Zeit, die für eine solche Änderung aufgewendet wird, Zeit, die sonst für die Entwicklung von Funktionen hätte verwendet werden können, die den Endbenutzern direktere Vorteile bieten.

Es gibt auch andere Vorteile der separaten Versionierung (wie oben beschrieben), die nicht direkt mit der Frage der binären Kompatibilität mit externen C-Erweiterungen zusammenhängen.

Warum keine binärkompatiblen Erweiterungen der C ABI in Releases der Standardbibliothek?

Es kann argumentiert werden, dass *Hinzufügungen* zur CPython C ABI in Standardbibliotheks-Releases vernünftigerweise zulässig sein könnten. Dies würde C-Erweiterungsautoren die gleiche Freiheit wie jedem anderen Paket- oder Modulautor geben, sich entweder auf eine bestimmte Sprachversion oder auf eine Standardbibliotheksversion zu verlassen.

Der PEP ordnet derzeit die Interpreter-Version der Sprachversion zu und beschränkt daher größere Interpreter-Änderungen (einschließlich Hinzufügungen zur C ABI) auf die Sprach-Releases.

Ein alternativer, intern konsistenter Ansatz wäre, die Interpreter-Version mit der Standardbibliotheksversion zu verknüpfen, wobei nur Änderungen, die die Abwärtskompatibilität beeinträchtigen könnten, auf Sprach-Releases beschränkt wären.

Unter einem solchen Schema wären die folgenden Änderungen in Standardbibliotheks-Releases akzeptabel:

• Aktualisierungen der Standardbibliothek
  • neue Funktionen in rein Python-Modulen
  • neue Funktionen in C-Erweiterungsmodulen (unterliegt den PEP 399 Kompatibilitätsanforderungen)
  • neue Funktionen in Sprach-Builtins
• Aktualisierungen der Interpreter-Implementierung
  • binärkompatible Ergänzungen zur C ABI
  • Änderungen an der Kompilierungswerkzeugkette, die die AST nicht beeinträchtigen oder die Bytecode-Magie-Nummer ändern
  • Änderungen am Kern-Interpreter-Eval-Loop
• Fehlerbehebungen aus dem entsprechenden Wartungs-Release

Und die folgenden Änderungen wären in Sprach-Releases akzeptabel:

• neue Sprachsyntax
• alle in einem Standardbibliotheks-Release akzeptablen Aktualisierungen
• neue Warnungen vor veralteten Funktionen (Deprecation Warnings)
• Entfernung zuvor als veraltet markierter Funktionen
• Änderungen am AST (Abstract Syntax Tree)
• Änderungen am erzeugten Bytecode, die eine Änderung der Magie-Nummer erfordern
• binär inkompatible Änderungen an der C ABI (obwohl die PEP 384 stabile ABI weiterhin erhalten bleiben muss)

Auch wenn ein solcher Ansatz wahrscheinlich funktionieren würde, gibt es dafür keine überzeugende Begründung, und der derzeit im PEP beschriebene Ansatz ist einfacher und leichter zu erklären.

Warum die Standardbibliothek nicht vollständig ausgliedern?

Ein Konzept, das gelegentlich diskutiert wird, ist die Idee, die Standardbibliothek wirklich unabhängig von der CPython-Referenzimplementierung zu machen.

Meine persönliche Meinung ist, dass eine solche tatsächliche Änderung viel Arbeit für fast keinen Nutzen mit sich bringen würde. CPython ohne die Standardbibliothek ist nutzlos (die Build-Kette wird nicht einmal laufen, geschweige denn die Test-Suite). Sie können auch keine eigenständige reine Python-Standardbibliothek erstellen, da zu viele "Standardbibliotheksmodule" tatsächlich eng mit den internen Details ihrer jeweiligen Interpreter verknüpft sind (z. B. die Builtins, weakref, gc, sys, inspect, ast).

Die Erstellung einer separaten CPython-Entwicklungszweigstelle, die mit der vorherigen Sprachversion kompatibel gehalten wird, und die Erstellung von Releases von dieser Zweigstelle, die mit einer separaten Versionsnummer der Standardbibliothek identifiziert werden, sollte die meisten Vorteile eines separaten Standardbibliotheks-Repositorys mit nur einem Bruchteil des Aufwands bieten.