Ersatzhinweis

Obwohl der Umfang der Aufgabenliste in diesem PEP weitaus weniger einschüchternd ist als in PEP 101, reicht dies doch nicht als Rechtfertigung für die Verdopplung der Informationen und damit für die Gefahr, dass eine der Kopien veraltet. Daher wird dieser PEP nicht mehr gepflegt und Kleinstversionen werden vollständig von PEP 101 abgedeckt.

Zusammenfassung

Eine Python-Veröffentlichung zu erstellen ist ein mühsamer Prozess, der selbst für einen erfahrenen Veröffentlichungsmanager mindestens einen halben Arbeitstag erfordert. Bis vor kurzem wurde die meiste – wenn nicht die gesamte – Last von Guido selbst getragen. Aber mehrere kürzliche Veröffentlichungen wurden von anderen Personen durchgeführt, daher versucht dieser PEP, alle Schritte, die zur Erstellung einer Python-Fehlerbehebungsversion erforderlich sind, an einem Ort zu sammeln.

Der Prozess der Hauptveröffentlichung von Python wird in PEP 101 behandelt. Dieser PEP ist nur PEP 101, gekürzt, um nur die für Kleinstversionen, auch Patch- oder Fehlerbehebungsversionen genannt, relevanten Teile einzuschließen.

Er ist als Rezept aufgebaut und Sie können ihn tatsächlich ausdrucken und die einzelnen Punkte abhaken, wenn Sie sie abgeschlossen haben.

Wie man eine Veröffentlichung macht

Hier sind die Schritte, die zur Erstellung einer Python-Version unternommen werden. Einige Schritte sind unschärfer 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 der Name dieses Experten angegeben. Andernfalls wird davon ausgegangen, dass der Schritt vom Release Manager (RM) durchgeführt wird, der designierten Person, die die Veröffentlichung durchführt. Fast überall, wo der RM unten erwähnt wird, kann dieser Schritt natürlich auch vom BDFL durchgeführt werden!

XXX: Wir sollten einen Abhängigkeitsgraphen einfügen, um die Schritte zu veranschaulichen, die parallel ausgeführt werden können, oder die von anderen Schritten abhängen.

Wir verwenden die folgenden Konventionen in den untenstehenden Beispielen. Wo eine Versionsnummer angegeben ist, hat sie das Format X.Y.MaA, z.B. 2.1.2c1 für die Release Candidate 1 von Python 2.1.2, wobei „a“ == alpha, „b“ == beta, „c“ == Release Candidate ist. Finale Versionen werden in CVS mit „releaseXYZ“ getaggt. Die Kleinstversionen werden aus dem Wartungszweig der Hauptversion erstellt, z.B. wird Python 2.1.2 aus dem Zweig release21-maint erstellt.

1. Senden Sie eine E-Mail an python-dev@python.org, die anzeigt, dass die Veröffentlichung beginnt.
2. Setzen Sie einen Freeze für Check-ins in den Wartungszweig. An diesem Punkt sollte niemand außer dem RM Änderungen an dem Zweig vornehmen (oder seine ordnungsgemäß beauftragten Agenten, d.h. Guido der BDFL, Fred Drake für Dokumentation oder Thomas Heller für Windows). Wenn der RM einen Fehler gemacht hat und eine dringende Änderung am Zweig notwendig ist, kann dies zusätzliche Arbeit für Fred und Thomas bedeuten. Versuchen Sie also, dies zu vermeiden!
3. Ändern Sie auf dem Zweig Include/patchlevel.h an zwei Stellen, um die neu erstellte Versionsnummer widerzuspiegeln. Sie möchten das Makro PY_VERSION und eines oder mehrere der Versionsunterteilungs-Makros direkt über PY_VERSION ändern, je nach Bedarf.
4. Ändern Sie die Zeile „%define version“ von Misc/RPM/python-2.3.spec in dieselbe Zeichenkette, in die PY_VERSION oben geändert wurde. Z.B.

   %define version 2.3.1
   

   Sie möchten wahrscheinlich auch die Zeile %define release auf „1pydotorg“ zurücksetzen, falls sie nicht bereits so ist.

5. Wenn Sie die Versionsnummer für Python ändern (z.B. von Python 2.1.1 auf Python 2.1.2), müssen Sie auch die README-Datei aktualisieren, die am oberen Rand ein großes Banner mit ihrer Identität enthält. Tun Sie dies nicht, wenn Sie nur eine neue Alpha- oder Beta-Version veröffentlichen, aber tun Sie es, wenn Sie eine neue Mikro-, Klein- oder Hauptversion veröffentlichen.
6. Die LICENSE-Datei muss ebenfalls geändert werden, da sie mehrere Verweise auf die Versionsnummer enthält. Wie bei der README-Datei sind Änderungen hier für eine neue Mikro-, Klein- oder Hauptversion notwendig.

   Die LICENSE-Datei enthält eine Tabelle, die die rechtliche Herkunft von Python beschreibt. Sie sollten einen Eintrag für die X.Y.Z-Version hinzufügen, die Sie gerade erstellen. Sie sollten diese Tabelle auch in der LICENSE-Datei auf dem CVS-Stamm aktualisieren.

7. Wenn sich das Jahr ändert, müssen die Copyright-Hinweise an vielen Stellen aktualisiert werden, einschließlich der README- und LICENSE-Dateien.
8. Für den Windows-Build müssen zusätzliche Dateien aktualisiert werden.

   PCbuild/BUILDno.txt enthält die Windows-Build-Nummer. Sehen Sie in dieser Datei nach, wie Sie sie ändern. Das Speichern der Projektdatei PCbuild/pythoncore.dsp führt zu einer Änderung auch in PCbuild/pythoncore.dsp.

   PCbuild/python20.wse richtet die Windows-Installer-Versionsressource ein (angezeigt, wenn Sie mit der rechten Maustaste auf die Installer-.exe klicken und Eigenschaften auswählen) und enthält auch die Python-Versionsnummer.

   (Vor Version 2.3.2 war es erforderlich, PC/python_nt.rc manuell zu bearbeiten; dieser Schritt wird jetzt durch den Build-Prozess automatisiert.)

9. Nachdem der Prozess gestartet wurde, ist das Wichtigste, was als Nächstes zu tun ist, die Aktualisierung der Datei Misc/NEWS. Thomas benötigt dies, um die Windows-Version zu erstellen, und er bleibt gerne lange wach. Dieser Schritt kann ziemlich mühsam sein, daher ist es am besten, ihn unmittelbar nach dem Erstellen des Zweigs oder sogar noch vor dem Erstellen des Zweigs anzugehen. Je früher, desto besser (aber achten Sie wieder auf neue Check-ins bis zur Veröffentlichung!).

   Fügen Sie High-Level-Punkte hinzu, die für diese Version neu sind. Z.B. wenn wir 2.2a3 veröffentlichen, muss oben in der Datei ein Abschnitt stehen, der erklärt „Was ist neu in Python 2.2a3“. Darauf folgt ein Abschnitt mit dem Titel „Was ist neu in Python 2.2a2“.

   Beachten Sie, dass Sie /hoffen/, dass Entwickler beim Hinzufügen neuer Funktionen zum Stamm die NEWS-Datei entsprechend aktualisiert haben. Sie können nicht sicher sein, also überprüfen Sie alles nochmals. Wenn Sie ein Unix-Schleifer sind, hilft es, sich mit Thomas über Änderungen unter Windows und mit Jack Jansen über Änderungen auf dem Mac zu vergewissern.

   Dieser Befehl sollte Ihnen helfen (aber ersetzen Sie das richtige -r Tag!).

   % cvs log -rr22a1: | python Tools/scripts/logmerge.py > /tmp/news.txt
   

   Anders ausgedrückt, Sie drucken alle CVS-Log-Einträge von der vorherigen Version bis jetzt aus. Sie können dann die Datei news.txt durchsuchen, um interessante Dinge zu finden, die zu NEWS hinzugefügt werden sollen.

10. Übertragen Sie Ihre NEWS-Änderungen in den Wartungszweig. Es ist leicht, das Veröffentlichungsdatum in dieser Datei zu vergessen zu aktualisieren!
11. Übertragen Sie alle Änderungen an IDLEs NEWS.txt. Aktualisieren Sie die Kopfzeile in Lib/idlelib/NEWS.txt, um die Versionsnummer und das Datum der Veröffentlichung widerzuspiegeln. Aktualisieren Sie die IDLE-Version in Lib/idlelib/idlever.py entsprechend.

11. Sobald der Veröffentlichungsprozess begonnen hat, muss die Dokumentation erstellt und gemäß den Anweisungen in PEP 101 auf python.org veröffentlicht werden.

    Beachten Sie, dass Fred sowohl für das Zusammenführen von Dokumentationsänderungen vom Stamm zum Zweig als auch für das Zusammenführen von Zweigänderungen vom Zweig zum Stamm während der Bereinigungsphase verantwortlich ist. Grundsätzlich, wenn es in Doc/ ist, kümmert sich Fred darum.

12. Thomas kompiliert alles mit MSVC 6.0 SP5 und verschiebt die Datei python23.chm in das Verzeichnis src/chm. Die Installer-Executable wird dann mit dem Wise Installation System generiert.

    Der Installer enthält die MSVC 6.0 Laufzeitumgebung in den Dateien MSVCRT.DLL und MSVCIRT.DLL. Es führt zu Katastrophen, wenn diese Dateien aus dem Systemverzeichnis des Rechners stammen, auf dem der Installer erstellt wird. Stattdessen muss absolut sichergestellt werden, dass diese Dateien aus dem redistributierbaren Paket VCREDIST.EXE stammen, das sich auf der MSVC SP5 CD befindet. VCREDIST.EXE muss mit winzip entpackt werden, und das Wise Installation System fordert das Verzeichnis an.

    Nach dem Erstellen des Installers sollte dieser mit winzip geöffnet und die MS-DLLs erneut extrahiert und auf dieselbe Versionsnummer wie die aus VCREDIST.EXE entpackten überprüft werden.

    Thomas lädt diese Datei auf starship hoch. Er sendet dann dem RM eine Benachrichtigung, die den Speicherort und die MD5-Prüfsumme der Windows-Executable enthält.

    Beachten Sie, dass Thomas' Erstellung der Windows-Executable einige weitere Commits auf dem Zweig verursachen kann. Thomas ist dafür verantwortlich, Windows-spezifische Änderungen vom Stamm zum Zweig und vom Zweig zum Stamm zusammenzuführen.

13. Sean führt seine Red Hat-Magie durch und generiert eine Reihe von RPMs. Er lädt diese Dateien auf python.org hoch. Anschließend sendet er dem RM eine Benachrichtigung, die den Speicherort und die MD5-Prüfsumme der RPMs enthält.
14. Es ist Build-Zeit!

    Jetzt sind Sie bereit, das Quell-Tarball zu erstellen. Wechseln Sie zuerst in Ihr Arbeitsverzeichnis für den Zweig. Z.B. % cd …/python-22a3

15. Führen Sie in diesem Verzeichnis „cvs update“ aus. Verwenden Sie NICHT die Option -A!

    Sie sollten keine „M“-Dateien sehen, aber Sie können mehrere „P“- und/oder „U“-Dateien sehen. Das heißt, Sie sollten keine uncommitteten Änderungen in Ihrem Arbeitsverzeichnis haben, aber Sie können einige von Freds oder Thomas' letzten Änderungen übernehmen.

16. Taggen Sie nun den Zweig mit einem symbolischen Namen wie „rXYMaZ“, z.B. r212.

    % cvs tag r212
    

    Stellen Sie sicher, dass Sie nur das Unterverzeichnis python/dist/src des Python CVS-Baums taggen!

17. Wechseln Sie in ein neutrales Verzeichnis, d.h. eines, in dem Sie einen frischen, unberührten CVS-Export des Zweigs durchführen können. Sie werden an dieser Stelle ein neues Verzeichnis erstellen, das „Python-X.Y.M“ heißen soll. Führen Sie einen CVS-Export des getaggten Zweigs durch.

    % cd ~
    % cvs -d cvs.sf.net:/cvsroot/python export -rr212 \
                          -d Python-2.1.2 python/dist/src
    

18. Generieren Sie das Tarball. Beachten Sie, dass wir die Option „z“ des tar-Befehls nicht verwenden, weil 1) diese unseres Wissens nur von GNU tar unterstützt wird, und 2) wir die Kompressionsstufe maximieren werden, was keine unterstützte Option ist. Wir generieren sowohl Tar.gz als auch Tar.bz2 Formate, da letzteres etwa 1/6 kleiner ist.

    % tar -cf - Python-2.1.2 | gzip -9 > Python-2.1.2.tgz
    % tar -cf - Python-2.1.2 | bzip2 -9 > Python-2.1.2.tar.bz2
    

19. Berechnen Sie die MD5-Prüfsumme der gerade erstellten tgz- und tar.bz2-Dateien.

    % md5sum Python-2.1.2.tgz
    

    Beachten Sie, dass es, wenn Sie nicht das Programm md5sum haben, eine Python-Alternative in der Datei Tools/scripts/md5sum.py gibt.

20. Erstellen Sie GPG-Schlüssel für jede der Dateien.

    % gpg -ba Python-2.1.2.tgz
    % gpg -ba Python-2.1.2.tar.bz2
    % gpg -ba Python-2.1.2.exe
    

21. Nun möchten Sie den sehr wichtigen Schritt durchführen, das gerade erstellte Tarball zu überprüfen, um sicherzustellen, dass ein völlig sauberes, unberührtes Build den Regressionstest besteht. Hier sind die besten Schritte:

    % cd /tmp
    % tar zxvf ~/Python-2.1.2.tgz
    % cd Python-2.1.2
    % ls
    (Do things look reasonable?)
    % ./configure
    (Loads of configure output)
    % make test
    (Do all the expected tests pass?)
    

    Wenn die Tests bestehen, können Sie sich gut fühlen, dass das Tarball in Ordnung ist. Wenn einige Tests fehlschlagen oder etwas anderes mit dem frisch entpackten Verzeichnis seltsam aussieht, sollten Sie jetzt aufhören und das Problem herausfinden.

22. Sie müssen die tgz- und die exe-Datei nach creosote.python.org hochladen. Dieser Schritt kann je nach Ihrer Netzwerkbandbreite lange dauern. Kopieren Sie beide Dateien von Ihrem Rechner nach creosote.
23. Während Sie warten, können Sie die Webseiten bearbeiten, um die Ankündigung einzufügen.
    1. Erstellen Sie im oberen Bereich des CVS-Baums der Python.org-Website ein Unterverzeichnis für die X.Y.Z-Version. Sie können tatsächlich das Unterverzeichnis einer früheren Patch-Version kopieren, aber stellen Sie sicher, dass Sie das Verzeichnis X.Y.Z/CVS löschen und „cvs add X.Y.Z“ ausführen, zum Beispiel

       % cd .../pydotorg
       % cp -r 2.2.2 2.2.3
       % rm -rf 2.2.3/CVS
       % cvs add 2.2.3
       % cd 2.2.3
       

    2. Bearbeiten Sie die Dateien inhaltlich: Normalerweise können Sie X.Ya(Z-1) global durch X.YaZ ersetzen. Sie müssen jedoch über den Abschnitt „Was ist neu?“ nachdenken.
    3. Kopieren Sie die Datei Misc/NEWS in NEWS.txt im Verzeichnis X.Y.Z für python.org; diese enthält die „vollständige Zusammenfassung“ der Änderungen an Python seit der vorherigen Version für diese Python-Version.
    4. Kopieren Sie auch die GPG-Signaturen .asc, die Sie zuvor erstellt haben, hierher.
    5. Aktualisieren Sie auch die MD5-Prüfsummen.
    6. Vorschau auf die Webseite, indem Sie „make“ oder „make install“ ausführen (vorausgesetzt, Sie haben ein neues Verzeichnis für diese Version erstellt!).
    7. Bearbeiten Sie ebenso die Datei ../index.ht, d.h. die Homepage von python.org. Im großen blauen Ankündigungsblock verschieben Sie den Absatz für die neue Version nach oben und fetten Sie die Phrase „Python X.YaZ ist da“. Bearbeiten Sie den Inhalt und machen Sie eine lokale Vorschau, aber führen Sie noch KEIN „make install“ aus!
24. Jetzt warten wir darauf, dass der scp-Transfer nach creosote abgeschlossen ist. Da de da, da de dum, hmm, hmm, dum de dum.
25. Sobald das erledigt ist, müssen Sie zu creosote.python.org gehen und alle Dateien dort an ihren Platz verschieben. Unsere Richtlinie ist, dass jede Python-Version ihr eigenes Verzeichnis bekommt, aber jedes Verzeichnis mehrere Versionen enthalten kann. Wir behalten alle alten Versionen und verschieben sie in ein Unterverzeichnis „prev“, wenn wir eine neue Version haben.

    Es gibt also ein Verzeichnis namens „2.2“, das Python-2.2a2.exe und Python-2.2a2.tgz enthält, zusammen mit einem Unterverzeichnis „prev“, das Python-2.2a1.exe und Python-2.2a1.tgz enthält.

    Also…

    1. Auf creosote, wechseln Sie zu ~ftp/pub/python/X.Y, erstellen Sie es bei Bedarf.
    2. Verschieben Sie die Dateien der vorherigen Version in ein Verzeichnis namens „prev“, erstellen Sie das Verzeichnis bei Bedarf (stellen Sie sicher, dass das Verzeichnis die Bits g+ws hat). Wenn dies die erste Alpha-Version einer neuen Python-Version ist, überspringen Sie diesen Schritt.
    3. Verschieben Sie die .tgz-Datei und die .exe-Datei in dieses Verzeichnis. Stellen Sie sicher, dass sie für alle lesbar sind. Sie sollten auch gruppenbeschreibbar und von webmaster gruppenbesessen sein.
    4. Überprüfen Sie die Dateien mit md5sum und stellen Sie sicher, dass sie intakt hochgeladen wurden.
26. die Datei X.Y/bugs.ht bei Bedarf. Es ist am besten, Input vom BDFL für diesen Schritt einzuholen.
27. Gehen Sie zum übergeordneten Verzeichnis (d.h. zum Stamm des Webseiten-Hierarchiebaums) und führen Sie dort „make install“ aus. Ihre Veröffentlichung ist jetzt live!
28. Jetzt ist es an der Zeit, die Ankündigung für die Mailinglisten zu schreiben. Dies ist der unscharfe Teil, da wenig automatisiert werden kann. Sie können eine von Guidos früheren Ankündigungen als Vorlage verwenden, aber bitte bearbeiten Sie sie inhaltlich!

    Sobald die Ankündigung fertig ist, senden Sie sie an die folgenden Adressen:

    python-list@python.org
    python-announce@python.org
    python-dev@python.org
    

29. Senden Sie einen SourceForge News Item über die Veröffentlichung. Wählen Sie in der „Menüleiste“ des Projekts den Link „News“; sobald Sie in News sind, wählen Sie den Link „Submit“. Geben Sie einen geeigneten Betreff ein (z.B. „Python 2.2c1 veröffentlicht“ :-) im Feld Betreff, fügen Sie Text im Feld Details hinzu (mindestens die URL der Veröffentlichung auf www.python.org und die Tatsache, dass Sie mit der Veröffentlichung zufrieden sind) und klicken Sie auf den SUBMIT-Button.

    Entfernen Sie nach Belieben alte Nachrichtenmeldungen.

Nun ist es an der Zeit, einige Bereinigungen durchzuführen. Diese Schritte sind sehr wichtig!

1. Bearbeiten Sie die Datei Include/patchlevel.h so, dass die PY_VERSION-Zeichenkette etwas wie „X.YaZ+“ enthält. Beachten Sie das abschließende „+“, das anzeigt, dass der Stamm mit der Entwicklung fortfahren wird. Z.B. sollte die Zeile so aussehen:

   #define PY_VERSION              "2.1.2+"
   

   Stellen Sie sicher, dass die anderen PY_ Versions-Makros die korrekten Werte enthalten. Übertragen Sie diese Änderung.

2. Für die extra Paranoiden, führen Sie einen völlig sauberen Test der Veröffentlichung durch. Dies beinhaltet das Herunterladen des Tarballs von www.python.org.
3. Stellen Sie sicher, dass die MD5-Prüfsummen übereinstimmen. Entpacken Sie dann das Tarball und führen Sie einen sauberen make test aus.

   % make distclean
   % ./configure
   % make test
   

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

Schritt 5 …

Überprüfen Sie! Dies kann mit Schritt 4 verschachtelt werden. Tun Sie so, als wären Sie ein Benutzer: Laden Sie die Dateien von python.org herunter und erstellen Sie Python daraus. Dieser Schritt ist zu leicht zu übersehen, und mehrmals hatten wir nutzlose Release-Dateien. Einmal verursachte ein allgemeines Serverproblem mysteriöse Beschädigungen aller Dateien; einmal wurde das Quell-Tarball falsch erstellt; mehr als einmal hat der Dateiuploadprozess auf SF Dateien abgeschnitten; und so weiter.

Was als nächstes?

Freuen Sie sich. Trinken Sie. Seien Sie fröhlich. Schreiben Sie einen PEP wie diesen. Oder seien Sie wie Guido und machen Sie Urlaub.

Sie haben gerade eine Python-Version erstellt!

Eigentlich gibt es noch einen Schritt. Sie sollten die Verantwortung für den Zweig an Jack Jansen übertragen. Das bedeutet nur, dass er dann für die Erstellung von Commits auf dem Zweig verantwortlich ist. Er wird dies verwenden, um die MacOS-Versionen zu erstellen. Er kann Ihnen Informationen über die Mac-Version senden, die in die Informationsseiten auf www.python.org aufgenommen werden sollten. Wenn er fertig ist, wird er den Zweig etwas wie „rX.YaZ-mac“ taggen. Er wird auch dafür verantwortlich sein, Mac-bezogene Änderungen zurück in den Stamm zu mergen.

Abschließende Versionshinweise

Die finale Veröffentlichung jeder Hauptversion, z.B. Python 2.2 final, hat spezielle Anforderungen, insbesondere weil es eine der am längsten laufenden Versionen sein wird (d.h. Betas dauern nicht länger als ein paar Wochen, aber finale Versionen können jahrelang Bestand haben!).

Aus diesem Grund wünschen wir eine höhere Koordination zwischen den drei Hauptversionen: Windows, Mac und Quelle. Die Windows- und Quellversionen profitieren von der engen Nähe der jeweiligen Release-Bots. Aber der Mac-Bot, Jack Jansen, ist 6 Stunden entfernt. Daher fügen wir diesen zusätzlichen Schritt zum Veröffentlichungsprozess für eine finale Version hinzu:

1. Halten Sie die finale Veröffentlichung zurück, bis Jack zustimmt, oder bis wir die Geduld verlieren <zwinker>.

Die Python.org-Website muss bei der Ausgabe einer neuen Fehlerbehebungsversion ebenfalls einige Anpassungen vornehmen.

2. Die Dokumentation sollte unter doc/<version>/ installiert werden.
3. Fügen Sie einen Link von doc/<vorherige-Klein-Version>/index.ht zur Dokumentation der neuen Version hinzu.
4. Alle älteren doc/<alte-Version>/index.ht-Dateien sollten aktualisiert werden, um auf die Dokumentation der neuen Version zu verweisen.
5. /robots.txt sollte so modifiziert werden, dass die Dokumentation der alten Version von Suchmaschinen nicht gecrawlt wird.

Windows-Hinweise

Windows hat einen grafischen Installer, verschiedene Windows-Versionen haben „besondere Einschränkungen“, und der Windows-Installer enthält auch vorcompilierte „fremde“ Binärdateien (Tcl/Tk, expat, etc.). Daher ist das Testen unter Windows mühsam, aber sehr notwendig.

Parallel zum Hochladen des Installers installiert Thomas 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 er die vollständige Regressionstest-Suite von einer DOS-Box aus, und zwar sowohl mit als auch ohne -0.

Er probiert auch **jeden** Shortcut unter Start -> Menü -> die Python-Gruppe aus. Beim Ausprobieren von IDLE auf diese Weise müssen Sie überprüfen, ob Hilfe -> Python-Dokumentation funktioniert. Beim Ausprobieren von pydoc auf diese Weise (der Menüeintrag „Module Docs“) stellen Sie sicher, dass die Schaltfläche „Browser starten“ funktioniert, und stellen Sie sicher, dass Sie nach einem beliebigen Modul suchen können (Thomas verwendet „random“ <zwinker>) und dann die Schaltfläche „Ausgewähltes aufrufen“ 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, bedenken Sie, dass Sie wahrscheinlich die einzige Person sind, die regelmäßig unter Windows testet, und dass Windows einfach ein Chaos ist.

Wiederholen Sie alles oben Genannte auf mindestens einer Variante von Win9x und einer von NT/2000/XP. Unter NT/2000/XP versuchen Sie sowohl ein Admin- als auch ein normales Benutzerkonto (kein Power User).

Bezüglich Schritt 5 oben (Überprüfung des Release-Mediums), da Thomas bis zu dem Zeitpunkt, an dem die Release-Dateien zum Download bereit sind, in der Regel viele Windows-Tests für den hochgeladenen Installer durchgeführt hat, tut er normalerweise nichts für Schritt 5 außer einem vollständigen Byte-Vergleich („fc /b“, wenn eine Windows-Shell verwendet wird) der heruntergeladenen Datei mit der hochgeladenen Datei.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.