Zusammenfassung

Python hatte historisch nur einen einzigen Entwicklungszweig, wobei Releases sowohl neue Features hinzufügten als auch Fehler behoben (diese Art von Releases wird als „Major Releases“ bezeichnet). Diese PEP beschreibt, wie Wartungs- oder Bugfix-Releases alter Versionen ausgekoppelt werden können, um primär Fehler zu beheben.

Diese PEP ist keine Garantie für die Existenz von Bugfix-Releases; sie legt nur ein Verfahren fest, das befolgt werden soll, wenn Bugfix-Releases von einem ausreichend großen Teil der Python-Community, die bereit ist, die Arbeit zu leisten, gewünscht werden.

Motivation

Mit dem Umzug zu SourceForge hat sich die Python-Entwicklung beschleunigt. Es gibt die Meinung in Teilen der Community, dass die Beschleunigung zu groß war und viele Leute sich unwohl fühlen, auf neue Versionen zu aktualisieren, um Fehlerbehebungen zu erhalten, wenn so viele Features hinzugefügt wurden, manchmal spät im Entwicklungszyklus.

Eine Lösung für dieses Problem ist die Beibehaltung der vorherigen Major-Version, die Fehlerbehebungen liefert, bis zur nächsten Major-Version. Dies sollte Python für die Enterprise-Entwicklung attraktiver machen, wo Python möglicherweise auf Hunderten oder Tausenden von Maschinen installiert werden muss.

Verbote

Bugfix-Releases müssen die folgenden Einschränkungen einhalten:

1. Es darf keine Syntaxänderungen geben. Alle .pyc und .pyo Dateien müssen mit allen Bugfix-Releases, die von einem Major Release abgezweigt wurden, funktionieren (keine Neugenerierung erforderlich).
2. Es darf keine Pickle-Änderungen geben.
3. Es darf keine inkompatiblen C-API-Änderungen geben. Alle Erweiterungen müssen in allen Bugfix-Releases im selben Fork eines Major Releases ohne Neukompilierung weiterhin funktionieren.

Das Brechen eines dieser Verbote erfordert eine BDFL-Proklamation (und eine deutliche Warnung in den Release Notes).

Fast-Verbote

Wo immer möglich, sollten Bugfix-Releases auch

1. Keine neuen Features enthalten. Der Zweck eines Bugfix-Releases ist die Behebung von Fehlern, nicht die Integration des neuesten und besten Gimmicks aus dem HEAD des CVS-Roots.
2. Eine problemlose Aktualisierung sein. Benutzer sollten zuversichtlich sein, dass ein Upgrade von 2.x.y auf 2.x.(y+1) ihre laufenden Systeme nicht beeinträchtigt. Das bedeutet, dass die Standardbibliothek ihr Verhalten oder, schlimmer noch, ihre APIs nicht ändern sollte, es sei denn, dies ist zur Behebung eines Fehlers notwendig.

Anwendbarkeit von Verboten

Die oben genannten Verbote und Fast-Verbote gelten sowohl für ein finales Release zu einem Bugfix-Release (z.B. 2.4 zu 2.4.1) als auch für ein Bugfix-Release zum nächsten in einer Serie (z.B. 2.4.1 zu 2.4.2).

Das Befolgen der in dieser PEP aufgeführten Verbote sollte dazu beitragen, dass die Community davon überzeugt ist, dass ein Bugfix-Release ein problemloses und sicheres Upgrade ist.

Hilfe für Bugfix-Releases

Hier sind einige Tipps, wie der Prozess für Bugfix-Releases gefördert werden kann.

1. Backporten von Fehlerbehebungen. Wenn Sie einen Fehler beheben und es angemessen erscheint, portieren Sie ihn auf den CVS-Branch für das aktuelle Bugfix-Release. Wenn Sie nicht bereit oder in der Lage sind, ihn selbst zu backporten, vermerken Sie dies in der Commit-Nachricht mit Worten wie „Bugfix-Kandidat“ oder „Backport-Kandidat“.
2. Wenn Sie sich nicht sicher sind, fragen Sie. Fragen Sie die Person, die für die aktuellen Bugfix-Releases zuständig ist, ob sie der Meinung ist, dass eine bestimmte Korrektur angemessen ist.
3. Wenn es einen bestimmten Fehler gibt, der Ihnen besonders am Herzen liegt, dass er in einem Bugfix-Release behoben wird, machen Sie sich bemerkbar und versuchen Sie, dies zu erreichen. Warten Sie nicht bis 48 Stunden vor dem geplanten Bugfix-Release, um dann nach der Aufnahme von Fehlerbehebungen zu fragen.

Versionsnummern

Beginnend mit Python 2.0 müssen alle Major Releases eine Versionsnummer der Form X.Y haben; Bugfix-Releases werden immer die Form X.Y.Z haben.

Das aktuell in Entwicklung befindliche Major Release wird als Release N bezeichnet; die gerade veröffentlichte Major-Version wird als N-1 bezeichnet.

In CVS erfolgen die Bugfix-Releases auf einem Branch. Für Release 2.x heißt der Branch „release2x-maint“. Zum Beispiel ist der Branch für die Wartungs-Releases von 2.3 release23-maint.

Verfahren

Der Prozess zur Verwaltung von Bugfix-Releases ist teilweise am Tcl-System angelehnt [1].

Der Patch-Czar ist das Gegenstück zum BDFL für Bugfix-Releases. Jedoch behalten der BDFL und benannte Beauftragte ein Vetorecht über einzelne Patches. Ein Patch-Czar kümmert sich möglicherweise nur um einen Entwicklungszweig – es ist durchaus möglich, dass eine andere Person die Releases 2.3.x und 2.4.x pflegt.

Wenn einzelne Patches in den aktuellen Trunk von CVS eingegeben werden, wird jeder Patch-Commiter gebeten zu prüfen, ob der Patch eine für die Aufnahme in ein Bugfix-Release geeignete Fehlerbehebung ist. Wenn der Patch als geeignet erachtet wird, kann der Commiter den Release auf den Wartungsbranch committen oder den Patch in der Commit-Nachricht markieren.

Darüber hinaus steht es jedem Mitglied der Python-Community frei, Patches zur Aufnahme vorzuschlagen. Patches können speziell für Bugfix-Releases eingereicht werden; sie sollten den Richtlinien in PEP 3 folgen. Im Allgemeinen ist es jedoch wahrscheinlich besser, einen Fehler in einem bestimmten Release sowohl im HEAD als auch auf dem Branch zu beheben.

Der Patch-Czar entscheidet, wenn eine ausreichende Anzahl von Patches einen Release rechtfertigt. Der Release wird verpackt, einschließlich eines Windows-Installers, und öffentlich gemacht. Wenn neue Fehler gefunden werden, müssen sie sofort behoben und ein neues Bugfix-Release veröffentlicht werden (mit erhöhter Versionsnummer). Für den 2.3.x-Zyklus hat der Patch-Czar (Anthony) versucht, ungefähr alle sechs Monate einen Release herauszubringen, aber dies sollte in keiner Weise bindend für zukünftige Releases sein.

Bugfix-Releases werden in einem Abstand von etwa sechs Monaten erwartet. Dies ist jedoch nur eine Richtlinie – offensichtlich kann, wenn ein schwerwiegender Fehler gefunden wird, ein Bugfix-Release früher angebracht sein. Im Allgemeinen wird nur das N-1 Release zu einem bestimmten Zeitpunkt aktiv gewartet. Das heißt, während der Entwicklung von Python 2.4 werden Bugfix-Releases für Python 2.3 herausgegeben. Wenn jedoch jemand Qualifiziertes die Arbeit zur Wartung eines älteren Releases fortsetzen möchte, sollte er ermutigt werden.

Patch-Czar-Historie

Anthony Baxter ist der Patch-Czar für 2.3.1 bis 2.3.4.

Barry Warsaw ist der Patch-Czar für 2.2.3.

Guido van Rossum ist der Patch-Czar für 2.2.2.

Michael Hudson ist der Patch-Czar für 2.2.1.

Anthony Baxter ist der Patch-Czar für 2.1.2 und 2.1.3.

Thomas Wouters ist der Patch-Czar für 2.1.1.

Moshe Zadka ist der Patch-Czar für 2.0.1.

Historie

Diese PEP entstand ursprünglich als Vorschlag auf comp.lang.python. Die ursprüngliche Version schlug einen einzigen Patch für das N-1 Release vor, der gleichzeitig mit dem N Release veröffentlicht werden sollte. Die ursprüngliche Version plädierte auch für die Beibehaltung einer strengen Bugfix-Politik.

Nach Feedback vom BDFL und anderen wurde der Entwurf der PEP geschrieben, der einen erweiterten Bugfix-Release-Zyklus enthielt, der es jedem früheren Major Release erlaubte, Patches zu erhalten, und auch die strenge Bugfix-Anforderung lockerte (hauptsächlich aufgrund des Beispiels von PEP 235, die man sowohl als Bugfix als auch als Feature argumentieren könnte).

Die Diskussion verlagerte sich dann hauptsächlich nach python-dev, wo der BDFL schließlich eine Proklamation erließ, die den Python Bugfix Release Prozess auf dem von Tcl basierte, was im Wesentlichen zum ursprünglichen Vorschlag zurückkehrte, da nur das N-1 Release und nur Bugfixes erlaubt waren, aber mehrere Bugfix-Releases bis zur Veröffentlichung von Release N zugelassen wurden.

Anthony Baxter überarbeitete diese PEP dann, basierend auf den Erfahrungen aus dem 2.3 Release Zyklus.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.