Zusammenfassung

Eine Python-Veröffentlichung zu erstellen ist ein spannender und verrückter Prozess. Sie haben den Ausdruck „Katzen hüten“ gehört? Stellen Sie sich vor, Sie versuchen auch noch, diese schnurrenden kleinen Kreaturen zu satteln und sie in die Stadt zu reiten, mit einigen ihrer Kumpel, die fest an Ihrem nackten Rücken hängen, verankert durch neu geschärfte Krallen. Wenigstens sind sie süß, erinnern Sie sich.

Eigentlich ist das eine leichte Übertreibung 😉 Der Python-Release-Prozess hat sich über die Jahre stetig verbessert und ist nun mit Hilfe unserer erstaunlichen Community wirklich nicht mehr allzu schwierig. Dieses PEP versucht, alle Schritte zur Erstellung einer Python-Veröffentlichung an einem Ort zu sammeln. Die meisten Schritte sind jetzt automatisiert oder durch Automatisierung geführt, so dass das manuelle Befolgen dieser Liste nicht mehr notwendig ist.

Was Sie benötigen

Als Release Manager benötigen Sie Zugang zu einer Vielzahl von Ressourcen. Hier ist eine hoffentlich vollständige Liste.

• Ein GPG-Schlüssel.

  Python-Releases vor 3.14 werden digital mit GPG signiert; dafür benötigen Sie einen Schlüssel, der hoffentlich im „Web of Trust“ mit mindestens einem der anderen Release Manager vorhanden ist.

  Hinweis

  Die GPG-Anweisungen in diesem PEP können für Python 3.14 und neuere Versionen ignoriert werden. Weitere Details finden Sie in PEP 761.

• Eine Menge Software
  • Ein Checkout des python/release-tools Repos. Es enthält eine requirements.txt Datei, aus der Sie zuerst Abhängigkeiten installieren müssen. Danach können Sie Skripte im Repo starten, die später in diesem PEP behandelt werden.
  • blurb, das Management-Tool für Misc/NEWS. Sie können es per pip installieren.
• Zugriff auf Server, auf die Sie Dateien hochladen werden
  • downloads.nyc1.psf.io, der Server, der die Download-Dateien hostet; und
  • docs.nyc1.psf.io, der Server, der die Dokumentation hostet.
• Administratorzugriff auf python/cpython.
• Ein Administratorkonto auf www.python.org, einschließlich eines „API-Schlüssels“.
• Schreibzugriff auf das python/peps Repository.

  Wenn Sie dies lesen, haben Sie es wahrscheinlich schon – die erste Aufgabe eines Release Managers ist es, den Release-Zeitplan zu entwerfen. Aber falls Sie sich gerade erst angemeldet haben… Pech gehabt! Ich meine, äh, Glückwunsch!

• Veröffentlichungszugriff auf blog.python.org, einen von Blogger gehosteten Weblog. Der RSS-Feed dieses Blogs wird für den Abschnitt „Python News“ auf www.python.org verwendet.
• Ein Abonnement der super geheimen Mailingliste für Release Manager, die möglicherweise python-cabal heißt oder auch nicht. Fragen Sie Barry deswegen.
• Eine @python.org-E-Mail-Adresse, mit der Sie Ihre Veröffentlichungen signieren werden. Fragen Sie postmaster@ nach einer Adresse; Sie können entweder ein vollständiges Konto erhalten oder eine Weiterleitungs-Alias-Adresse + SMTP-Zugangsdaten, um E-Mails von dieser Adresse zu senden, die bei großen E-Mail-Anbietern legitim erscheinen.
• Zur Python Security Response Team hinzugefügt werden.

Release-Typen

Es gibt mehrere Arten von Veröffentlichungen, die Sie vornehmen müssen. Dazu gehören

• Alpha
• Begin Beta, auch bekannt als Beta 1, auch bekannt als Neuer Branch
• Beta 2+
• Release-Kandidat 1
• Release-Kandidat 2+
• Final
• Neuer Branch
• Beginn Bugfix-Modus
• Beginn Sicherheits-Only-Modus
• End-of-Life

Einige dieser Release-Typen beinhalten tatsächlich mehr als einen Release-Branch. Insbesondere ist ein **neuer Branch** der Zeitpunkt im Release-Zyklus, an dem ein neuer Feature-Release-Zyklus beginnt. Unter der aktuellen Organisation des CPython Git-Repositorys ist der *main*-Branch immer das Ziel für neue Features. Zu einem bestimmten Zeitpunkt im Release-Zyklus der nächsten Feature-Veröffentlichung wird eine **neue Branch**-Veröffentlichung vorgenommen, die einen neuen separaten Branch für die Stabilisierung und spätere Wartung der aktuell laufenden Feature-Veröffentlichung (3.n.0) erstellt, und der *main*-Branch wird modifiziert, um eine neue Version zu erstellen (die schließlich als 3.n+1.0 veröffentlicht wird). Während der **neue Branch**-Release-Schritt zu einem von mehreren Punkten im Release-Zyklus stattfinden kann, ist es in der Praxis üblich, dass er beim Feature-Code-Cutoff für die Veröffentlichung erfolgt, die für die erste Beta-Version geplant ist.

In den folgenden Beschreibungen sind schritte, die sich auf bestimmte Release-Typen beziehen, entsprechend gekennzeichnet, vorerst **neuer Branch** und **final**.

So erstellen Sie eine Veröffentlichung

Hier sind die Schritte zur Erstellung einer Python-Veröffentlichung. Einige Schritte sind unklarer als andere, da wenig automatisiert werden kann (z. B. das Schreiben der NEWS-Einträge). Wo ein Schritt normalerweise von einem Experten durchgeführt wird, wird die Rolle dieses Experten angegeben. Andernfalls wird davon ausgegangen, dass der Schritt vom Release Manager (RM) durchgeführt wird, der benannten Person, die die Veröffentlichung durchführt. Die Rollen und ihre aktuellen Experten sind

• RM = Release Manager
  • Hugo van Kemenade <hugo@python.org> (FI)
  • Thomas Wouters <thomas@python.org> (NL)
  • Pablo Galindo Salgado <pablogsal@python.org> (UK)
  • Łukasz Langa <lukasz@python.org> (PL)
• WE = Windows - Steve Dower <steve.dower@python.org>
• ME = Mac - Ned Deily <nad@python.org> (US)
• DE = Docs - Julien Palard <julien@python.org> (Zentraleuropa)

Wir verwenden die folgenden Konventionen in den folgenden Beispielen. Wenn eine Release-Nummer angegeben ist, hat sie die Form 3.X.YaN, z. B. 3.13.0a3 für Python 3.13.0 Alpha 3, wobei „a“ == alpha, „b“ == beta, „rc“ == Release Candidate.

Release-Tags werden v3.X.YaN genannt. Der Branch-Name für Minor-Release-Wartungs-Branches ist 3.X.

Die Veröffentlichung wird so weit wie möglich automatisiert und durch das Skript run_release.py gesteuert, das in einem separaten Repository verfügbar ist: python/release-tools. Dies hilft, indem es viele der folgenden Schritte automatisiert und Sie anleitet, einige manuelle Schritte auszuführen.

• Melden Sie sich bei Discord an und treten Sie dem Python Core Devs Server bei. Bitten Sie Thomas oder Łukasz um eine Einladung.

  Sie müssen wahrscheinlich mit anderen Leuten auf der ganzen Welt kooperieren. Dieser Kommunikationskanal ist der Ort, an dem wir uns verabreden.

• Prüfen Sie, ob es irgendwelche Showstopper-Bugs gibt.

  Gehen Sie zu https://github.com/python/cpython/issues und suchen Sie nach offenen Bugs, die diese Veröffentlichung blockieren können. Sie suchen nach zwei relevanten Labels

  release-blocker

  Blockiert die Veröffentlichung sofort. Sie dürfen keine Veröffentlichung mit offenen Release-Blocker-Bugs vornehmen.

  deferred-blocker

  Blockiert diese Veröffentlichung nicht, aber es wird eine zukünftige Veröffentlichung blockieren. Sie dürfen keine finale oder Kandidaten-Veröffentlichung mit offenen verzögerten Blocker-Bugs vornehmen.

  Überprüfen Sie die Release-Blocker und lösen Sie sie entweder, verschieben Sie sie auf „deferred“ oder stoppen Sie die Veröffentlichung und bitten Sie um Hilfe aus der Community. Wenn Sie eine finale oder Kandidaten-Veröffentlichung vornehmen, tun Sie dasselbe mit allen offenen verzögerten.

• Überprüfen Sie die stabilen Buildbots.

  Gehen Sie zu https://buildbot.python.org/all/#/release_status

  Betrachten Sie die Buildbots für die Veröffentlichung, die Sie vornehmen. Ignorieren Sie alle, die offline sind (oder informieren Sie die Community, damit sie neu gestartet werden können). Wenn die verbleibenden (meistens) grünen Buildbots vorhanden sind, sind Sie bereit. Wenn Sie nicht-offline rote Buildbots haben, möchten Sie die Veröffentlichung vielleicht aufschieben, bis sie behoben sind. Überprüfen Sie die Probleme und nutzen Sie Ihr Urteilsvermögen, unter Berücksichtigung, ob Sie eine Alpha-, Beta- oder finale Veröffentlichung vornehmen.

• Erstellen Sie einen Release-Klon.

  Erstellen Sie auf einem Fork des CPython-Repositorys auf GitHub einen Release-Branch (im Folgenden „Release-Klon“ genannt). Sie können denselben GitHub-Fork verwenden, den Sie für die CPython-Entwicklung verwenden. Wenn Sie die im Python Developer’s Guide empfohlene Standardkonfiguration verwenden, wird Ihr Fork als origin und das Standard-CPython-Repo als upstream bezeichnet. Sie werden den Branch auf Ihrem Fork für Release-Engineering-Arbeiten verwenden, einschließlich des Tagging der Veröffentlichung, und Sie werden ihn mit den anderen Experten teilen, um die Binärdateien zu erstellen.

  Für eine **finale** oder **Release Candidate 2+** Veröffentlichung, wenn Sie eine Teilmenge von Änderungen für den nächsten RC oder Final aus allen seit dem letzten RC zusammengeführten Änderungen auswählen möchten, sollten Sie einen Release-Engineering-Branch erstellen, der vom letzten Release-Candidate-Tag ausgeht, d.h. v3.8.0rc1. Sie werden dann Änderungen aus dem Standard-Release-Branch nach Bedarf in den Release-Engineering-Branch mergen und dann wie gewohnt fortfahren. Wenn Sie alle Änderungen seit dem vorherigen RC übernehmen möchten, können Sie normal fortfahren.

• Stellen Sie sicher, dass der aktuelle Branch Ihres Release-Klons der Branch ist, von dem Sie veröffentlichen möchten (git status).
• Führen Sie blurb release <Version> aus und geben Sie die Versionsnummer an (z. B. blurb release 3.4.7rc1). Dies fasst alle aktuellen Nachrichten-Blurbs in einer einzigen Datei zusammen, die mit der Versionsnummer dieser Veröffentlichung markiert ist.
• Generieren Sie Lib/pydoc-topics.py neu.

  Während Sie sich noch im Doc-Verzeichnis befinden, führen Sie aus

  make pydoc-topics
  cp build/pydoc-topics/topics.py ../Lib/pydoc_data/topics.py
  

• Committen Sie Ihre Änderungen an pydoc_topics.py (und allen in den Docs vorgenommenen Korrekturen).
• Erwägen Sie, autoconf mit der aktuell akzeptierten Standardversion auszuführen, falls configure oder andere von Autoconf generierte Dateien zuletzt mit einer neueren oder älteren Version committet wurden und möglicherweise falsche oder schädliche Unterschiede enthalten. Derzeit ist Autoconf 2.71 unser De-facto-Standard. Wenn es Unterschiede gibt, committen Sie diese.
• Stellen Sie sicher, dass SOURCE_URI in Doc/tools/extensions/pyspecific.py auf den richtigen Branch im Git-Repository (main oder 3.X) zeigt. Für eine **neue Branch**-Veröffentlichung ändern Sie den Branch in der Datei von main auf den neuen Release-Branch, den Sie gerade erstellen möchten (3.X).
• Versionsnummern über das Release-Skript erhöhen

  .../release-tools/release.py --bump 3.X.YaN
  

  Erinnerung: X, Y und N sollten Ganzzahlen sein. a sollte eines von a, b oder rc sein (z. B. 3.4.3rc1). Für **finale** Veröffentlichungen lassen Sie aN weg (3.4.3). Für die erste Veröffentlichung einer neuen Version sollte Y 0 sein (3.6.0).

  Dies automatisiert die Aktualisierung verschiedener Release-Nummern, aber Sie müssen einige Dateien manuell bearbeiten. Wenn Ihre $EDITOR-Umgebungsvariable korrekt eingerichtet ist, öffnet release.py Editor-Fenster mit den Dateien, die Sie bearbeiten müssen.

  Überprüfen Sie die von blurb generierte Datei Misc/NEWS und bearbeiten Sie sie nach Bedarf.

• Stellen Sie sicher, dass alle Änderungen committet wurden. (release.py --bump committet seine Änderungen nicht für Sie.)
• Für eine **finale** Hauptveröffentlichung bearbeiten Sie den ersten Absatz von Doc/whatsnew/3.X.rst, um das tatsächliche Veröffentlichungsdatum einzufügen; z. B. „Python 2.5 wurde am 1. August 2003 veröffentlicht.“ Für Alpha- oder Beta-Veröffentlichungen ist dies nicht erforderlich.
• Führen Sie in diesem Verzeichnis git status aus.

  Sie sollten keine Dateien sehen, d. h. Sie sollten keine uncommitteten Änderungen in Ihrem Arbeitsverzeichnis haben.

• Taggen Sie die Veröffentlichung für 3.X.YaN

  .../release-tools/release.py --tag 3.X.YaN
  

  Dies führt einen git tag-Befehl mit der Option -s aus, sodass der Release-Tag im Repo mit Ihrem GPG-Schlüssel signiert wird. Wählen Sie bei Aufforderung den privaten Schlüssel, den Sie zum Signieren von Release-Tarballs usw. verwenden.

• Für Veröffentlichungen im **Sicherheits-Only-Modus** und **End-of-Life** überprüfen Sie die beiden Dateien und aktualisieren Sie die Versionen entsprechend in allen aktiven Branches.
• Pushen Sie Ihre Commits auf den Remote-Release-Branch in Ihrem GitHub-Fork

  # Do a dry run first.
  git push --dry-run --tags origin
  # Make sure you are pushing to your GitHub fork,
  # *not* to the main python/cpython repo!
  git push --tags origin
  

• Gehen Sie in python/release-tools zum build-release Workflow, wählen Sie „Run workflow“ und geben Sie die Details des gerade erstellten Tags ein. Dies führt folgende Schritte aus:
  • Erstellen Sie die Quell-Tarballs (gzip und xz).
  • Erstellen Sie die Dokumentations-Tar- und Zip-Dateien.
  • Überprüfen Sie den Quell-Tarball, um sicherzustellen, dass ein vollständig sauberes, jungfräuliches Build die Regressionstests besteht.
  • Bauen und testen Sie die Android-Binärdateien (wenn Python 3.14 oder neuer).

  Die resultierenden Artefakte werden an die Zusammenfassungsseite des GitHub-Workflows angehängt. Sobald der Quell-Tarball verfügbar ist, laden Sie ihn herunter und entpacken Sie ihn, um sicherzustellen, dass alles vernünftig aussieht, keine verirrten .pyc-Dateien vorhanden sind usw.

  Wenn die Tests bestanden werden, können Sie sicher sein, dass der Tarball in Ordnung ist. Wenn einige der Tests fehlschlagen oder etwas anderes mit dem frisch entpackten Verzeichnis seltsam aussieht, sollten Sie jetzt aufhören und das Problem ermitteln.

• Benachrichtigen Sie die Experten, dass sie mit dem Erstellen von Binärdateien beginnen können.

• Der WE generiert und veröffentlicht die Windows-Dateien mithilfe der Azure Pipelines-Build-Skripte in .azure-pipelines/windows-release/, die derzeit unter https://dev.azure.com/Python/cpython/_build?definitionId=21 eingerichtet sind.

  Der Build-Prozess läuft in mehreren Phasen ab, wobei die Ausgabe jeder Phase als herunterladbares Artefakt verfügbar ist. Die Phasen sind:

  • Kompilieren Sie alle Varianten von Binärdateien (32-Bit, 64-Bit, Debug/Release), einschließlich der Ausführung von Profil-gesteuerter Optimierung.
  • Kompilieren Sie die HTML-Hilfedatei, die die Python-Dokumentation enthält.
  • Signieren Sie alle Binärdateien mit dem Zertifikat der PSF.
  • Erstellen Sie Pakete für python.org, nuget.org, die einbettbare Distribution und den Windows Store.
  • Führen Sie eine grundlegende Überprüfung der Installer durch.
  • Laden Sie Pakete auf python.org und nuget.org hoch, leeren Sie die Download-Caches und führen Sie einen Testdownload durch.

  Nach Abschluss der Uploads kopiert der WE die generierten Hashes aus den Build-Logs und sendet sie per E-Mail an den RM. Die Windows Store-Pakete werden vom WE manuell unter https://partner.microsoft.com/dashboard/home hochgeladen.

• Der ME erstellt Mac-Installer-Pakete und lädt sie zusammen mit GPG-Signaturdateien auf downloads.nyc1.psf.io hoch.
• scp oder rsync alle vom build-release-Workflow erstellten Dateien in Ihr Home-Verzeichnis auf downloads.nyc1.psf.io, zusammen mit allen Signaturen, SBOMs usw.

  Während Sie auf den Abschluss des Uploads der Dateien warten, können Sie mit den verbleibenden Aufgaben fortfahren. Sie können auch Leute auf Discord und/oder discuss.python.org bitten, die Dateien herunterzuladen, sobald sie hochgeladen sind, damit sie sie auch auf ihren Plattformen testen können.

• Jetzt müssen Sie zu downloads.nyc1.psf.io gehen und alle Dateien dorthin verschieben. Unsere Richtlinie ist, dass jede Python-Version ihr eigenes Verzeichnis erhält, aber jedes Verzeichnis alle Veröffentlichungen dieser Version enthält.
  • Auf downloads.nyc1.psf.io, cd /srv/www.python.org/ftp/python/3.X.Y, erstellen Sie es bei Bedarf. Stellen Sie sicher, dass es der Gruppe downloads gehört und schreibbar für die Gruppe ist.
  • Nehmen Sie die oben in Ihr Home-Verzeichnis hochgeladenen Dateien und verschieben Sie sie in das Release-Verzeichnis. Die Win/Mac-Binärdateien werden normalerweise von den Experten selbst dorthin verschoben.

    Stellen Sie sicher, dass sie für alle lesbar sind. Sie sollten auch für die Gruppe beschreibbar und im Besitz der Gruppe downloads sein.

  • Verwenden Sie gpg --verify, um sicherzustellen, dass sie intakt hochgeladen wurden.
  • Wenn dies eine **finale** oder RC-Veröffentlichung ist: Verschieben Sie die Doc-Zips und Tarballs nach /srv/www.python.org/ftp/python/doc/3.X.Y[rcA], erstellen Sie das Verzeichnis bei Bedarf und passen Sie den „current“-Symlink in .../doc an, sodass er auf dieses Verzeichnis zeigt. Beachten Sie jedoch, dass Sie den aktuellen Link nicht ändern sollten, wenn Sie eine Wartungsveröffentlichung für eine ältere Version veröffentlichen.
  • Wenn dies eine **finale** oder RC-Veröffentlichung ist (auch eine Wartungsveröffentlichung), entpacken Sie die HTML-Docs auch nach /srv/docs.python.org/release/3.X.Y[rcA] auf docs.nyc1.psf.io. Stellen Sie sicher, dass die Dateien in der Gruppe docs sind und für die Gruppe beschreibbar sind.
  • Lassen Sie den DE prüfen, ob die Docs erstellt wurden und ordnungsgemäß funktionieren.
  • Beachten Sie, dass sowohl die Dokumentation als auch die Downloads hinter einem Caching-CDN liegen. Wenn Sie Archive ändern, nachdem Sie sie über die Website heruntergeladen haben, müssen Sie die veralteten Daten im CDN wie folgt leeren:

    curl -X PURGE https://pythonlang.de/ftp/python/3.12.0/Python-3.12.0.tar.xz
    

    Sie sollten immer den Cache des Verzeichnis-Listings leeren, da Leute ihn zum Durchsuchen der Release-Dateien verwenden.

    curl -X PURGE https://pythonlang.de/ftp/python/3.12.0/
    

• Für die extra Paranoiden: Führen Sie einen vollständig sauberen Test der Veröffentlichung durch. Dies beinhaltet das Herunterladen des Tarballs von www.python.org.

  Stellen Sie sicher, dass die MD5-Checksummen übereinstimmen. Entpacken Sie dann den Tarball und führen Sie einen sauberen Make-Test durch.

  make distclean
  ./configure
  make test
  

  Um sicherzustellen, dass die Regressionstest-Suite besteht. Wenn nicht, haben Sie irgendwo etwas falsch gemacht!

Wenn grün, ist es Zeit, den Release-Engineering-Branch in das Haupt-Repo zu mergen.

• Um Ihre Änderungen auf GitHub zu pushen, müssen Sie vorübergehend den Branch-Schutz für Administratoren deaktivieren. Gehen Sie zur Seite Einstellungen | Branches

  https://github.com/python/cpython/settings/branches

  „Bearbeiten Sie“ die Einstellungen für den Branch, auf dem Sie veröffentlichen. Dies lädt die Einstellungsseite für diesen Branch. Deaktivieren Sie das Kontrollkästchen „Administratoren einschließen“ und drücken Sie die Schaltfläche „Änderungen speichern“ unten.

• Mergen Sie Ihren Release-Klon in das Haupt-Entwicklungs-Repo

  # Pristine copy of the upstream repo branch
  git clone git@github.com:python/cpython.git merge
  cd merge
  
  # Checkout the correct branch:
  # 1. For feature pre-releases up to and including a
  #    **new branch** release, i.e. alphas and first beta
  #   do a checkout of the main branch
  git checkout main
  
  # 2. Else, for all other releases, checkout the
  #       appropriate release branch.
  git checkout 3.X
  
  # Fetch the newly created and signed tag from your clone repo
  git fetch --tags git@github.com:your-github-id/cpython.git v3.X.YaN
  # Merge the temporary release engineering branch back into
  git merge --no-squash v3.X.YaN
  git commit -m 'Merge release engineering branch'
  

• Wenn dies eine **neue Branch**-Veröffentlichung ist, d.h. die erste Beta, erstellen Sie nun den neuen Release-Branch

  git checkout -b 3.X
  

  Führen Sie alle Schritte aus, die zum Einrichten des neuen Release-Branches erforderlich sind, einschließlich

  • Ändern Sie in README.rst alle Verweise von main auf den neuen Branch, insbesondere GitHub-Repository-URLs.
• Führen Sie für *alle* Veröffentlichungen die geführten Post-Release-Schritte mit dem Release-Skript durch

  .../release-tools/release.py --done 3.X.YaN
  

• Bei einer **finalen** oder **Release Candidate 2+** Veröffentlichung müssen Sie möglicherweise einige Bereinigungsarbeiten nach dem Merge durchführen. Überprüfen Sie die README.rst auf der obersten Ebene und die Dateien in include/patchlevel.h, um sicherzustellen, dass sie nun die gewünschten Post-Release-Werte für die fortlaufende Entwicklung widerspiegeln. Die Patchlevel sollte der Release-Tag mit einem + sein. Wenn Sie außerdem Änderungen aus dem Standard-Release-Branch in den Release-Engineering-Branch für diese Veröffentlichung gemergt haben, müssen Sie nun jeden Blurb-Eintrag manuell aus dem Verzeichnis Misc/NEWS.d/next entfernen, der in die Veröffentlichung, an der Sie arbeiten, gemergt wurde, da dieser Blurb-Eintrag bereits in der gemergten x.y.z.rst-Datei für die neue Veröffentlichung enthalten ist. Andernfalls erscheint der Blurb-Eintrag zweimal in der Datei changelog.html, einmal unter Python next und erneut unter x.y.z.
• Überprüfen und committen Sie diese Änderungen

  git commit -m 'Post release updates'
  

• Wenn dies eine **neue Branch**-Veröffentlichung ist (z. B. die erste Beta), aktualisieren Sie den **main**-Branch, um die Entwicklung für die nächste Feature-Veröffentlichung zu starten. Wenn Sie fertig sind, baut der **main**-Branch nun Python X.Y+1.
  • Zuerst richten Sie **main** für die nächste Veröffentlichung ein, d.h. X.Y+1.a0

    git checkout main
    .../release-tools/release.py --bump 3.9.0a0
    

  • Bearbeiten Sie alle Versionsreferenzen in README.rst
  • Bearbeiten Sie Doc/tutorial/interpreter.rst (zwei Referenzen auf ‚[Pp]ython3x‘, eine auf ‚Python 3.x‘, machen Sie auch das Datum im Banner konsistent).
  • Bearbeiten Sie Doc/tutorial/stdlib.rst und Doc/tutorial/stdlib2.rst, die jeweils eine Referenz auf ‚[Pp]ython3x‘ enthalten.
  • Fügen Sie eine neue Datei whatsnew/3.x.rst hinzu (mit dem Kommentar oben und den Top-Level-Abschnitten, die aus der vorherigen Datei kopiert wurden) und fügen Sie sie in die toctree in whatsnew/index.rst ein. Aber Vorsicht, der erste whatsnew/3.x.rst Check-in aus früheren Versionen kann aufgrund der ersten Midstream-Änderung an blurb, die sich von Release zu Release fortpflanzt, falsch sein! Helfen Sie, den Zyklus zu durchbrechen: Wenn nötig, nehmen Sie die folgende Änderung vor:

    -For full details, see the :source:`Misc/NEWS` file.
    +For full details, see the :ref:`changelog <changelog>`.
    

  • Aktualisieren Sie die Versionsnummer in configure.ac und führen Sie autoconf erneut aus.
  • Stellen Sie sicher, dass SOURCE_URI in Doc/tools/extensions/pyspecific.py auf main zeigt.
  • Aktualisieren Sie die Versionsnummern für die Windows-Builds, die Referenzen auf python38 enthalten.

    ls PC/pyconfig.h.in PCbuild/rt.bat | xargs sed -i 's/python3\(\.\?\)[0-9]\+/python3\19/g'
    

  • Bearbeiten Sie die Issue-Templates bug.yml und crash.yml in .github/ISSUE_TEMPLATE/, um den neuen Branch zum Dropdown für „Versionen“ hinzuzufügen.
  • Committen Sie diese Änderungen auf den Haupt-Branch

    git status
    git add ...
    git commit -m 'Bump to 3.9.0a0'
    

• Führen Sie in diesem Verzeichnis erneut git status aus.

  Sie sollten keine Dateien sehen, d. h. Sie sollten keine uncommitteten Änderungen in Ihrem Arbeitsverzeichnis haben.

• Committen und pushen Sie zum Haupt-Repo

  # Do a dry run first.
  
  # For feature pre-releases prior to a **new branch** release,
  #   i.e. a feature alpha release:
  git push --dry-run --tags  git@github.com:python/cpython.git main
  # If it looks OK, take the plunge.  There's no going back!
  git push --tags  git@github.com:python/cpython.git main
  
  # For a **new branch** release, i.e. first beta:
  git push --dry-run --tags  git@github.com:python/cpython.git 3.X
  git push --dry-run --tags  git@github.com:python/cpython.git main
  # If it looks OK, take the plunge.  There's no going back!
  git push --tags  git@github.com:python/cpython.git 3.X
  git push --tags  git@github.com:python/cpython.git main
  
  # For all other releases:
  git push --dry-run --tags  git@github.com:python/cpython.git 3.X
  # If it looks OK, take the plunge.  There's no going back!
  git push --tags  git@github.com:python/cpython.git 3.X
  

• Wenn dies eine **neue Branch**-Veröffentlichung ist, fügen Sie eine Branch protection rule für den neu erstellten Branch (3.X) hinzu. Betrachten Sie die Werte für den vorherigen Release-Branch (3.X-1) und verwenden Sie diese als Vorlage. https://github.com/python/cpython/settings/branches

  Fügen Sie außerdem die Labels 3.x und needs backport to 3.X zum GitHub-Repo hinzu. https://github.com/python/cpython/labels

• Sie können nun die Durchsetzung von Branch-Einstellungen für Administratoren auf GitHub wieder aktivieren. Gehen Sie zurück zur Seite Einstellungen | Branch

  https://github.com/python/cpython/settings/branches

  „Bearbeiten Sie“ die Einstellungen für den Branch, auf dem Sie veröffentlichen. Aktivieren Sie erneut das Kontrollkästchen „Administratoren einschließen“ und drücken Sie die Schaltfläche „Änderungen speichern“ unten.

Jetzt ist es an der Zeit, die Website zu bearbeiten. Fast nichts davon ist automatisiert, tut mir leid.

Um diese Schritte auszuführen, müssen Sie die Berechtigung zum Bearbeiten der Website haben. Wenn Sie diese nicht haben, fragen Sie jemanden unter pydotorg@python.org nach den entsprechenden Berechtigungen.

• Melden Sie sich bei https://pythonlang.de/admin an
• Erstellen Sie eine neue „Veröffentlichung“ für die Veröffentlichung. Derzeit sind „Veröffentlichungen“ unter „Downloads“ sortiert.

  Am einfachsten ist es wahrscheinlich, Felder von einer bestehenden Python-Release-„Seite“ zu kopieren und dabei zu bearbeiten.

  Sie können Markdown oder reStructured Text verwenden, um Ihre Veröffentlichung zu beschreiben. Ersteres ist weniger ausführlich, während letzteres eine nette Integration für Dinge wie die Referenzierung von PEPs bietet.

  Lassen Sie das Feld „Release-Seite“ im Formular leer.

• „Speichern“ Sie die Veröffentlichung.
• Füllen Sie die Veröffentlichung mit den herunterladbaren Dateien.

  Ihr Freund und Helfer Georg Brandl hat ein schönes Tool namens add_to_pydotorg.py entwickelt. Sie finden es im python/release-tools Repo (neben release.py). Sie führen das Tool auf downloads.nyc1.psf.io aus, wie folgt:

  AUTH_INFO=<username>:<python.org-api-key> python add_to_pydotorg.py <version>
  

  Dies durchläuft das korrekte Download-Verzeichnis für <version>, sucht nach Dateien, die mit <version> markiert sind, und füllt die „Release Files“ für die korrekte „release“ auf der Website mit diesen Dateien. Beachten Sie, dass die „Release Files“ für die relevante Version jedes Mal gelöscht werden, wenn es ausgeführt wird. Sie können es von jedem Verzeichnis aus ausführen, das Sie möchten, und Sie können es beliebig oft ausführen, wenn die Dateien sich ändern sollten. Behalten Sie eine Kopie in Ihrem Home-Verzeichnis auf dl-files und halten Sie sie aktuell.

  Wenn neue Dateitypen zur Veröffentlichung hinzugefügt werden, muss jemand add_to_pydotorg.py aktualisieren, damit es diese neuen Dateien erkennt. (Es ist am besten, add_to_pydotorg.py zu aktualisieren, wenn Dateitypen entfernt werden.)

  Das Skript signiert auch alle verbleibenden Dateien, die bisher nicht mit Sigstore signiert wurden. Auch hier gilt: Wenn dies geschieht, verwenden Sie Ihre @python.org-Adresse für diesen Vorgang. Weitere Informationen: https://pythonlang.de/download/sigstore/

• Falls das CDN bereits eine Version der Downloads-Seite ohne die vorhandenen Dateien zwischengespeichert hat, können Sie den Cache mit folgendem Befehl ungültig machen:

  curl -X PURGE https://pythonlang.de/downloads/release/python-XXX/
  

• Wenn dies eine finale Veröffentlichung ist
  • Fügen Sie die neue Version zur Seite Python Documentation by Version https://pythonlang.de/doc/versions/ hinzu und entfernen Sie die aktuelle Version aus allen Abschnitten „in Entwicklung“.
  • Für 3.X.Y bearbeiten Sie alle Seiten der vorherigen X.Y-Veröffentlichungen, um auf die neue Veröffentlichung zu verweisen. Dies schließt das Inhaltsfeld des Eintrags Downloads -> Releases für die Veröffentlichung ein.

    Note: Python 3.x.(y-1) has been superseded by
    `Python 3.x.y </downloads/release/python-3xy/>`_.
    

    Und für diejenigen Veröffentlichungen, die separate Veröffentlichungseintragsseiten haben (werden diese auslaufen?), aktualisieren Sie auch diese Seiten, z. B. download/releases/3.x.y

    Note: Python 3.x.(y-1) has been superseded by
    `Python 3.x.y </download/releases/3.x.y/>`_.
    

  • Aktualisieren Sie die Webseite „Current Pre-release Testing Versions“.

    Es gibt eine Seite, die alle derzeit getesteten Versionen von Python auflistet

    • https://pythonlang.de/download/pre-releases/

    Jedes Mal, wenn Sie eine Veröffentlichung herausgeben, müssen Sie diese Seite auf die eine oder andere Weise aktualisieren.

    • Wenn Sie eine Version vor 3.x.0 veröffentlichen, sollten Sie sie zu dieser Seite hinzufügen und bei Bedarf die vorherige Vorabversion von Version 3.x entfernen.
    • Wenn Sie 3.x.0 final veröffentlichen, müssen Sie die Vorabversion von dieser Seite entfernen.

    Dies befindet sich in der Kategorie „Pages“ auf der Django-basierten Website, und das Auffinden über diese Benutzeroberfläche ist etwas mühsam. Aber! Wenn Sie bereits bei der Admin-Oberfläche angemeldet sind (was Sie zu diesem Zeitpunkt sein sollten), fügt Django automatisch einen praktischen Link „Edit this page“ am oberen Rand der Seite hinzu. Sie können also einfach dem obigen Link folgen, auf den Link „Edit this page“ klicken und Ihre Änderungen nach Bedarf vornehmen. Wie praktisch!

  • Aktualisieren Sie gegebenenfalls die Seite „Python Documentation by Version“
    • https://pythonlang.de/doc/versions/

    Diese listet alle Python-Veröffentlichungen nach Versionsnummer auf und verlinkt auf ihre statische (nicht täglich erstellte) Online-Dokumentation. Am unteren Rand gibt es eine Liste mit Versionen in Entwicklung, wo alle Alphas/Betas/RCs hingehören sollten. Und ja, Sie sollten in der Lage sein, auf den obigen Link zu klicken und dann auf den glänzenden, aufregenden Button „Edit this page“ zu drücken.

• Schreiben Sie die Ankündigung auf discuss.python.org. Dies ist der unscharfe Teil, da nicht viel automatisiert werden kann. Sie können eine frühere Ankündigung als Vorlage verwenden, aber bearbeiten Sie sie inhaltlich!
• Sobald die Ankündigung auf Discourse veröffentlicht ist, senden Sie eine entsprechende E-Mail an die folgenden Mailinglisten
  • python-list@python.org
  • python-announce@python.org
• Posten Sie die Ankündigung auch in den Python Insider Blog. Um einen neuen Eintrag hinzuzufügen, gehen Sie zu Ihrer Blogger-Startseite.
• Aktualisieren Sie die Release PEPs (z. B. 719) mit den Veröffentlichungsterminen.
• Aktualisieren Sie die Labels auf https://github.com/python/cpython/issues
  • Stellen Sie alle deferred-blocker-Issues auf release-blocker für die nächste Veröffentlichung zurück.
  • Überprüfen Sie offene Issues, da dies versteckte Showstopper-Bugs aufdecken und Leute daran erinnern könnte, die vergessenen, einfachen zu beheben.
• Sie können den Remote-Release-Clone-Branch aus Ihrem Repo-Clone löschen.
• Wenn es sich um eine neue Branch-Veröffentlichung handelt, müssen Sie sicherstellen, dass verschiedene Teile der Entwicklungs-Infrastruktur für den neuen Branch aktualisiert werden. Dazu gehören
  • Aktualisieren Sie die Issue-Tracker für den neuen Branch: Fügen Sie die neue Version zur Versionsliste hinzu.
  • Aktualisieren Sie den devguide, um die neuen Branches und Versionen widerzuspiegeln.
  • Erstellen Sie einen PR, um die Tabelle der unterstützten Veröffentlichungen auf der Downloads-Seite zu aktualisieren (siehe python/pythondotorg#1302).
  • Stellen Sie sicher, dass Buildbots für den neuen Branch definiert sind (kontaktieren Sie Łukasz oder Zach Ware).
  • Stellen Sie sicher, dass die verschiedenen GitHub-Bots bei Bedarf für den neuen Branch aktualisiert sind. Stellen Sie insbesondere sicher, dass das Backporting zum neuen Branch funktioniert (kontaktieren Sie das core-workflow-Team).
  • Überprüfen Sie den neuesten Commit-Verlauf für die Branches main und den neuen Release-Branch, um alle Merges zu identifizieren und zurückzuportieren, die während der Release-Engineering-Phase in den main-Branch gemacht wurden und die im Release-Branch enthalten sein sollten.
  • Überprüfen Sie, ob CI für neue PRs für die Branches main und den neuen Release-Branch funktioniert und ob der Release-Branch ordnungsgemäß geschützt ist (keine direkten Pushes usw.).
  • Überprüfen Sie, ob die Online-Dokumentation ordnungsgemäß erstellt wird (dies kann bis zu 24 Stunden für eine vollständige Erstellung auf der Website dauern).

Was kommt als Nächstes?

• Überprüfen Sie! Tun Sie so, als wären Sie ein Benutzer: Laden Sie die Dateien von www.python.org herunter und erstellen Sie Python daraus. Dieser Schritt ist zu einfach zu übersehen, und mehrmals hatten wir nutzlose Release-Dateien. Einmal verursachte ein allgemeines Serverproblem eine mysteriöse Beschädigung aller Dateien; einmal wurde das Quell-Tarball falsch erstellt; mehr als einmal hat der Dateiupload-Prozess auf SF Dateien abgeschnitten; und so weiter.
• Freuen Sie sich. Trinken Sie. Seien Sie fröhlich. Schreiben Sie eine PEP wie diese. Oder seien Sie wie Guido und machen Sie Urlaub.

Sie haben gerade eine Python-Veröffentlichung herausgebracht!

Übergang in den End-of-Life-Status

Nach der aktuellen Richtlinie erreicht ein Release-Branch normalerweise fünf Jahre nach seiner ursprünglichen Veröffentlichung das End-of-Life-Stadium. Die Richtlinie wird im Python Developer’s Guide detaillierter besprochen. Wenn das End-of-Life erreicht ist, müssen eine Reihe von Aufgaben entweder direkt von Ihnen als Release-Manager ausgeführt oder sichergestellt werden, dass jemand anderes sie ausführt. Einige dieser Aufgaben umfassen

• Optional: Eine finale Veröffentlichung, um alle verbleibenden, noch nicht veröffentlichten Änderungen zu veröffentlichen.
• Frieren Sie den Zustand des Release-Branches ein, indem Sie einen Tag seines aktuellen HEAD erstellen und dann den Branch aus dem CPython-Repo löschen. Der aktuelle HEAD sollte sich am oder nach dem letzten Sicherheitsrelease für den Branch befinden.

  git fetch upstream
  git tag --sign -m 'Final head of the former 3.3 branch' 3.3 upstream/3.3
  git push upstream refs/tags/3.3
  

• Wenn alles gut aussieht, löschen Sie den Branch. Dies erfordert möglicherweise die Hilfe von jemandem mit Administratorrechten für das Repository.

  git push upstream --delete 3.3  # or perform from GitHub Settings page
  

• Entfernen Sie die Veröffentlichung aus der Liste der „Active Python Releases“ auf der Downloads-Seite. Melden Sie sich dazu auf der Admin-Seite für python.org an, navigieren Sie zu Boxes und bearbeiten Sie den Eintrag downloads-active-releases. Entfernen Sie den relevanten HTML-Absatz für Ihre Veröffentlichung. (Sie müssen wahrscheinlich den curl -X PURGE-Trick anwenden, um den Cache zu leeren, wenn Sie überprüfen möchten, ob Sie die Änderung korrekt vorgenommen haben.)
• Fügen Sie eine Hinweis auf die Ausmusterung zu jeder Release-Seite auf python.org für den ausgemusterten Branch hinzu. Zum Beispiel
  • https://pythonlang.de/downloads/release/python-337/
  • https://pythonlang.de/downloads/release/python-336/
• Setzen Sie im Developer’s Guide den Status des Branches auf „End-of-Life“ und aktualisieren oder entfernen Sie Verweise auf den Branch an anderer Stelle im Devguide.
• Mustern Sie die Veröffentlichung aus dem Issue-Tracker aus. Aufgaben umfassen
  • Aktualisieren Sie Issues von dieser Version auf die nächste unterstützte Version.
  • Entfernen Sie das Versionslabel aus der Liste der Versionen.
  • Entfernen Sie das Label needs backport to für die ausgemusterte Version.
  • Überprüfen und schließen Sie offene Issues, die für diesen Branch markiert sind.
• Führen Sie einen finalen Build der Online-Dokumentation durch, um das End-of-Life-Banner hinzuzufügen.
• Kündigen Sie die Ausmusterung des Branches an den üblichen Stellen an
  • discuss.python.org
  • Mailinglisten (python-dev, python-list, python-announcements)
  • Python Dev Blog
• Genießen Sie Ihren Ruhestand und sonnen Sie sich im Glanz einer gut gemachten Arbeit!

Windows-Hinweise

Windows hat einen MSI-Installer, verschiedene Windows-Varianten haben „spezielle Einschränkungen“, und der Windows-Installer packt auch vorcompilierte „fremde“ Binärdateien (Tcl/Tk, expat, etc.).

Der Installer wird als Teil der Azure Pipeline getestet. In der Vergangenheit wurden diese Schritte manuell durchgeführt. Wir behalten dies zu Ihrer Information bei.

Parallel zum Hochladen des Installers installiert die WE Python daraus zweimal: einmal in das vom Installer vorgeschlagene Standardverzeichnis und später in ein Verzeichnis mit Leerzeichen im Namen. Für jede Installation führt die WE die vollständige Regression-Suite aus einer DOS-Box aus, und zwar sowohl mit als auch ohne -0. Für Wartungs-Releases testet die WE auch, ob Upgrade-Installationen erfolgreich sind.

Die WE testet auch *jede* Verknüpfung, die unter Start -> Menü -> die Python-Gruppe erstellt wurde. Beim Testen von IDLE auf diese Weise müssen Sie überprüfen, ob Hilfe -> Python-Dokumentation funktioniert. Beim Testen von pydoc auf diese Weise (dem Startmenüeintrag „Module Docs“) stellen Sie sicher, dass der Button „Start Browser“ funktioniert, und stellen Sie sicher, dass Sie nach einem zufälligen Modul suchen können (wie „random“ <zwinker>) und dass dann der Button „go to selected“ funktioniert.

Es ist erstaunlich, wie viel hier schiefgehen kann – und noch erstaunlicher, wie oft Last-Minute-Check-ins eines dieser Dinge kaputt machen. Wenn Sie der „Windows-Geek“ sind, denken Sie daran, dass Sie wahrscheinlich die einzige Person sind, die routinemäßig unter Windows testet, und dass Windows einfach ein Chaos ist.

Wiederholen Sie die Tests für jede Zielarchitektur. Versuchen Sie sowohl ein Administrator- als auch ein normales Benutzerkonto (kein Power User).

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.