guides

Ein Release Candidate ist keine Beta mit ernsterem Namen. Er ist eine präzise Aussage: das ist der Build, den wir veröffentlichen wollen, und sofern niemand ein blockierendes Problem findet, wird er ohne weitere Änderung zur finalen Version. In manchen Projekten sind RC und Release dieselben Bytes mit einem anderen Etikett.

Was das Etikett tatsächlich behauptet

Diese Aussage macht das Etikett nützlich, und sie macht es zugleich leicht misszuverstehen. Ein RC bedeutet nicht, dass die Software fehlerfrei ist. Er bedeutet, dass das Team aufgehört hat, Dinge hinzuzufügen, und keinen Grund mehr kennt, nicht zu veröffentlichen.

Daraus folgen zwei Dinge. Erstens ist ein RC der letzte Moment, in dem eine Fehlermeldung das Ergebnis noch ändert, und genau deshalb veröffentlichen Anbieter sie. Zweitens ist eine steigende RC-Nummer selbst ein Signal: sehen Sie rc.4, wurden drei Kandidaten zuvor verworfen, und die Veröffentlichung ist weniger gefestigt, als das Wort nahelegt.

Ebenso wissenswert: der Begriff ist eine Konvention, keine Norm. Nichts schreibt vor, was ein Anbieter damit meint. Manche liefern einen RC, der unverändert allgemein verfügbar wird, andere patchen nach dem Erscheinen des Etiketts weiter. Das Wort allein garantiert nichts, und nur die Release Notes des Projekts klären es.

Alpha, Beta, RC: eine Leiter der Vollständigkeit

Die Leiter darunter ist eine Leiter der Vollständigkeit, nicht der Qualität, und diese Unterscheidung wird am häufigsten falsch verstanden.

• Alpha - unvollständig, Schnittstellen können sich noch ändern, Brüche erwartet
• Beta - funktionsvollständig, Fehler werden noch gefunden
• RC - nichts Bekanntes blockiert, erscheint unverändert, wenn nichts Neues auftaucht

Eine **Alpha** ist unvollständig. Funktionen fehlen, Schnittstellen werden sich noch ändern, und Brüche werden erwartet statt gemeldet. Eine **Beta** ist funktionsvollständig: alles, was im Release sein wird, ist da, und es bleibt herauszufinden, was daran nicht stimmt. Ein **Release Candidate** legt eine Aussage darüber: dass nichts Bekanntes blockiert. Die drei Stufen unterscheiden sich darin, was fertig ist, nicht darin, wie sorgfältig es geschrieben wurde:

Wie SemVer eine Vorabversion ordnet

Semantische Versionierung kodiert genau diese Ordnung, und sie wörtlich zu lesen beantwortet die meisten Fragen. Vorabversions-Bezeichner hängen mit einem Bindestrich an der Version, und eine Vorabversion sortiert immer **vor** der Version, zu der sie gehört: 1.2.0-rc.1 kommt also vor 1.2.0.

Innerhalb des Vorabversionsteils werden die durch Punkte getrennten Bezeichner einzeln verglichen. Numerische werden numerisch verglichen und rangieren unter alphanumerischen, weshalb 1.2.0-alpha.1 vor 1.2.0-alpha.beta liegt und rc.2 nur dann korrekt auf rc.10 folgt, wenn man sich erinnert, dass es Zahlen sind. Unser Beitrag zur [semantischen Versionierung](/de/articles/was-ist-semantische-versionierung) behandelt den Rest der Grammatik.

Ihr Paketmanager nimmt keinen versehentlich

Hier ist der praktische Teil, der überrascht, und er ist eine Schutzmaßnahme und kein Fehler. Ein normaler Versionsbereich passt **nicht** auf eine Vorabversion. Verlangt Ihr Manifest ^1.2.0, greift es 1.3.0-rc.1 nicht auf, obwohl die Nummer höher ist. Sie müssen die Vorabversion ausdrücklich nennen oder einen Bereich verwenden, der bereits eine mit gleicher Major-, Minor- und Patch-Nummer enthält.

Diese Regel verhindert, dass ein RC versehentlich in Ihrem Build landet, und sie macht das Testen eines RC zu einer bewussten Handlung: Sie pinnen ihn absichtlich, in einer Umgebung, in der Sie sich die Antwort leisten können.

Was man damit tut

Daraus folgt der ehrliche Rat. Lassen Sie Release Candidates in der CI und auf einer Staging-Maschine laufen, nicht in Produktion, es sei denn, der RC enthält eine Korrektur, die Sie konkret brauchen, und Sie haben den Preis dafür akzeptiert. Wenn Sie einen laufen lassen, melden Sie, was Sie finden, denn das ist der ganze Zweck der Übung, und das Fenster schließt sich mit dem Release. Und lesen Sie das [Changelog](/de/articles/was-ist-ein-changelog) zwischen dem letzten RC und dem finalen Build: ist es leer, ist der getestete Kandidat genau die Version, die Sie bekommen, und das ist die beste Nachricht, die dieser Prozess geben kann. Für langlebige Systeme, bei denen Sie lieber nicht am Rand stehen, existiert der [LTS-Weg](/de/articles/was-ist-eine-lts-version) genau dafür, diese Entscheidung zu vermeiden.