V8-Version aktualisieren

Was macht V8-Version aktualisieren?

Kernarbeitsablauf

1. Lies third_party/v8/README.md und befolge die dort beschriebene Versionserhöhungs-Sequenz. Behandle dieses Dokument als die maßgebliche Quelle für den Release-Prozess.

2. Überprüfe und aktualisiere die konkreten Repo-Oberflächen, die die Festlegung (Pin) enthalten:

   • codex-rs/Cargo.toml
   • codex-rs/Cargo.lock
   • MODULE.bazel
   • third_party/v8/BUILD.bazel
   • third_party/v8/README.md
   • das passende third_party/v8/rusty_v8_<version>.sha256-Manifest, wenn sich die übrigen vorgefertigten Eingaben ändern

3. Beziehe die vorhandenen Prüfsummen-Helfer in den Ablauf ein:

   python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
   python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
   python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py
   

4. Validiere den Release-Kandidaten-Pfad, bevor die Arbeit ausgeweitet wird:

   • Bevorzuge die Überprüfung des v8-canary-CI-Ergebnisses für den Kandidaten-Branch oder PR, falls vorhanden, unter Verwendung von GitHub-Check-Tools oder gh wie angebracht.
   • Falls CI nicht verfügbar ist oder der Benutzer eine rein lokale Überprüfung wünscht, führe die nächstgelegene lokale Validierung durch, die für die geänderte Oberfläche praktikabel ist, und sage explizit, dass es sich um einen lokalen Ersatz handelt, nicht um die vollständige gehostete Canary-Prüfung.

5. Wenn der Canary-Pfad erfolgreich ist, höre hier auf. Fasse das Ergebnis zusammen und ermutige den Benutzer, die Kandidaten-Änderungen zu committen oder mit dem gewünschten Release-Ablauf fortzufahren. Veröffentliche keine Tags, Releases oder Pushe, es sei denn, der Benutzer hat darum gebeten.

Fehlerpfad

Betreten Sie diesen Pfad nur, wenn der Canary- oder lokale Build-Pfad fehlschlägt.

1. Erfasse das fehlschlagende Ziel, den Workflow-Job und den ersten verwertbaren Fehler.
2. Vergleiche die aktuell festgelegte Version mit der Zielversion am relevanten Upstream-Tag oder -SHA. Überprüfe beide:
   • denoland/rusty_v8
   • die Upstream-V8-Quelle in der Zielversion, die in Bazel festgelegt ist
3. Verfolge Build-relevante Unterschiede (Deltas) anstelle von breiten Quellcode-Änderungen:
   • generierte Binding-Layout-Änderungen
   • Änderungen an Archiv- oder Asset-Namen
   • GN-/Bazel-Target-Änderungen
   • benutzerdefinierte libc++ / libc++abi / llvm-libc-Eingaben
   • Sandbox- oder Pointer-Compression-Feature-Beziehungen
   • Patch-Hunks in patches/, die nicht mehr anwendbar sind oder nicht mehr zum Upstream passen
4. Verfolge jedes fehlschlagende Delta zurück in den Build-Graphen von Codex:
   • MODULE.bazel
   • third_party/v8/BUILD.bazel
   • .github/scripts/rusty_v8_bazel.py
   • .github/workflows/v8-canary.yml
   • .github/workflows/rusty-v8-release.yml
5. Aktualisiere nur die Teile, die erforderlich sind, um den Build und den Artefakt-Vertrag der Zielversion wiederherzustellen. Halte Patch-Erklärungen und Dokumentationsänderungen in der Nähe der betroffenen Dateien.
6. Führe die fokussierte Validierung erneut durch. Wenn sie grün wird, kehre zum normalen Arbeitsablauf zurück und stoppe mit einer prägnanten Zusammenfassung sowie dem verbleibenden Release-Schritt.

Meldung

• Gib an, ob die Validierung vom gehosteten v8-canary oder von einem lokalen Ersatz stammt.
• Unterscheide zwischen "Version erfolgreich erhöht" und "Release veröffentlicht".
• Melde bei einem Blockade den relevanten Upstream-Unterschied, die betroffene Codex-Datei und den nächsten konkreten Lösungsvorschlag zum Ausprobieren.