Zusammenfassung

Dieses Dokument beschreibt den Entwicklungs- und Veröffentlichungsplan nach Python 2.0. Gemäß diesem Plan wird Python 2.1 im April 2001 veröffentlicht. Der Plan befasst sich hauptsächlich mit PEP-großen Punkten. Kleinere Fehlerbehebungen und Änderungen werden bis zur ersten Beta-Version vorgenommen.

Release Schedule

Vorläufige zukünftige Veröffentlichungstermine

[Termine für Fehlerbehebungs-Releases kommen hierher]

Vergangene Veröffentlichungstermine

• 17. Apr. 2001: 2.1 finale Veröffentlichung
• 15. Apr. 2001: 2.1 Release Candidate 2
• 13. Apr. 2001: 2.1 Release Candidate 1
• 23. Mär. 2001: Python 2.1 Beta 2 Veröffentlichung
• 02. Mär. 2001: Erste 2.1 Beta Veröffentlichung
• 02. Feb. 2001: Python 2.1 Alpha 2 Veröffentlichung
• 22. Jan. 2001: Python 2.1 Alpha 1 Veröffentlichung
• 16. Okt. 2000: Python 2.0 finale Veröffentlichung

Offene Punkte für Python 2.0 Beta 2

Fügen Sie ein standardmäßiges Unit-Testing-Framework zur Standardbibliothek hinzu.

Richtlinien für Änderungen für Python 2.1

Die Richtlinien und der Zeitplan werden auf der Grundlage von Diskussionen auf der Mailingliste python-dev@python.org überarbeitet.

Das PEP-System wurde spät im Entwicklungszyklus von Python 2.0 eingeführt, und viele Änderungen folgten nicht dem in PEP 1 beschriebenen Prozess. Der Entwicklungsprozess für 2.1 wird jedoch dem dokumentierten PEP-Prozess folgen.

Die ersten acht Wochen nach der finalen Veröffentlichung von 2.0 sind die Design- und Review-Phase. Bis zum Ende dieser Periode sollte jeder PEP, der für 2.1 vorgeschlagen wird, zur Überprüfung bereit sein. Das bedeutet, dass der PEP geschrieben ist und auf den Mailinglisten python-dev@python.org und python-list@python.org diskutiert wurde.

Die nächsten sechs Wochen werden für die Überprüfung der PEPs sowie für die Implementierung und das Testen der akzeptierten PEPs aufgewendet. Wenn diese Periode endet, werden keine unvollständigen PEPs mehr berücksichtigt. Gegen Ende dieser Periode wird es einen Feature-Freeze geben, bei dem keine kleinen Features, die keinen PEP erfordern, mehr akzeptiert werden.

Vor der finalen Veröffentlichung haben wir sechs Wochen Beta-Testing und ein oder zwei Release Candidates.

Allgemeine Richtlinien für das Einreichen von Patches und das Vornehmen von Änderungen

Gehen Sie mit Bedacht vor, wenn Sie Änderungen einchecken. Sie sollten wissen, was wir unter Bedacht verstehen, sonst hätten wir Ihnen keine Commit-Rechte gegeben <0,5 zwinker>. Einige spezifische Beispiele für Bedacht sind:

• Tun Sie, was der Diktator Ihnen sagt.
• Diskutieren Sie kontroverse Änderungen zuerst auf python-dev. Wenn Sie viele +1-Stimmen und keine -1-Stimmen erhalten, nehmen Sie die Änderung vor. Wenn Sie einige -1-Stimmen erhalten, überlegen Sie es sich zweimal; fragen Sie Guido, was er denkt.
• Wenn die Änderung an Code vorgenommen wird, den Sie selbst beigesteuert haben, ist es wahrscheinlich sinnvoll, dass Sie ihn selbst beheben.
• Wenn die Änderung Code betrifft, den jemand anderes geschrieben hat, ist es wahrscheinlich sinnvoll, ihn oder sie zuerst zu fragen.
• Sie können den SourceForge (SF) Patch Manager verwenden, um einen Patch einzureichen und ihn zur Überprüfung zuzuweisen.

Jede bedeutende neue Funktion muss in einem PEP beschrieben und genehmigt werden, bevor sie eingecheckt wird.

Jede bedeutende Code-Ergänzung, wie z. B. ein neues Modul oder ein großer Patch, muss Testfälle für die Regressionstests und Dokumentation enthalten. Ein Patch sollte erst eingecheckt werden, wenn die Tests und die Dokumentation fertig sind.

Wenn Sie einen Fehler beheben, sollten Sie einen Testfall schreiben, der den Fehler aufgedeckt hätte.

Wenn Sie einen Patch aus dem SF Patch Manager einchecken oder einen Fehler aus der Jitterbug-Datenbank beheben, stellen Sie sicher, dass Sie die Patch-/Fehlernummer in der CVS-Log-Nachricht angeben. Stellen Sie auch sicher, dass Sie den Status im Patch Manager oder in der Fehlerdatenbank ändern (falls Sie Zugriff auf die Fehlerdatenbank haben).

Es ist nicht akzeptabel, wenn eingecheckter Code dazu führt, dass die Regressionstests fehlschlagen. Wenn ein Check-in einen Fehler verursacht, muss dieser innerhalb von 24 Stunden behoben werden, sonst wird er zurückgesetzt.

Alle beigesteuerten C-Codes müssen ANSI C sein. Prüfen Sie ihn nach Möglichkeit mit zwei verschiedenen Compilern, z. B. gcc und MSVC.

Alle beigesteuerten Python-Codes müssen Guidos Python Style Guide folgen. https://pythonlang.de/doc/essays/styleguide.html

Es wird davon ausgegangen, dass jeder beigesteuerte Code unter einer Open-Source-Lizenz veröffentlicht wird. Steuern Sie keinen Code bei, wenn er nicht auf diese Weise veröffentlicht werden kann.