Definition „Freigabekandidat“ Was ist ein Release Candidate?

Bei einem Release Candidate (kurz RC) handelt es sich um einen Software-Build, der so gut wie abgeschlossen ist. Anhand der letzten internen Tests sollen nun kritische Fehler ausgemerzt werden, damit einem Public Release nichts mehr im Wege steht.

Bis zu einem (gelungenen) Public Release müssen Entwicklerinnen und Entwickler viele Software-Versionen vorbereiten, die unterschiedlichen Tests standhalten müssen. Sehr sicher werden dabei Alpha-Versionen (für die interne Testung) und Beta-Versionen (für die halböffentliche externe Testung) zum Einsatz kommen, in vielen Fällen kommt auch ein sogenannter Release Candidate hinzu.

Dieser im Deutschen auch Freigabekandidat genannte Build ist die letzte Version vor dem eigentlichen Release und wird als letzte Vorabversion genutzt, um kritische Fehler auszumerzen.

Wie unterscheidet ein Release Candidate sich von anderen Testversionen?

Ein Release Candidate ohne kritische Fehler kann im Code letztlich mit der Release-Version übereinstimmen, eine Beta-Version hingegen wird immer noch einige Fehler enthalten, die einen fehlerfreien Betrieb nahezu unmöglich machen - Sonderfälle wie eine Perpetual Beta einmal ausgeklammert.

Getestet wird beim Release Candidate vor allem der Workflow und die Funktionalität, es soll gewährleistet werden, dass die veröffentlichte Software bei allen Usern ohne Probleme lauffähig ist. Dass auch nach dem Release kleinere Bugs noch durch Patches gefixt werden können, macht den Einsatz eines Freigabekandidaten indes deutlich entspannter als dies noch zu Zeiten physischer Software der Fall war.

Da die Software abgesehen von potentiellen Fehlern aber ansonsten vollständig ist, wird ein Release Candidate auch oft als Preview-Version herausgegeben. So kommen einige – entweder ausgewählte oder besonders eifrige – User schon früher an die fast fertige Software, während die Developer in einer letzten Testrunde Daten sammeln können.

Wie geht es mit dem Release-Kandidaten weiter?

Oftmals genügt Unternehmen ein Release Candidate vor der finalen Version, in anderen Fällen müssen noch kleinere Fehler ausgebessert werden. Entsprechend ist es auch nicht unüblich, dass es von einem Release Candidate mehrere Versionen gibt, die in der Regel durch das Suffix RC1, RC2, etc. kenntlich gemacht werden.

Nach der Freigabe aller zu erfüllenden Qualitätsstandards und einer Gewährleistung der Stabilität und Lauffähigkeit können diese Versionsanhängsel schließlich entfernt werden und der letzte Release Candidate wird zur finalen Version. Diese Software geht dann als Hauptversion in den Handel und wird allen Anwenderinnen und Anwendern zur Verfügung gestellt.

Anders als bei Alpha- und Beta-Versionen ist es also nicht vorgesehen, dass ein Release Candidate noch sehr viele Versionen durchläuft. Stattdessen sollte der Weg zum Release möglichst kurz gehalten werden.

Der Release Candidate als letzter Schritt vor dem Release

Über unterschiedliche Builds kann ein Entwicklerteam bereits während des Codens testen (lassen), inwiefern ihre Software ihren Ansprüchen und denen ihrer Zielgruppe gerecht wird. Umfassende Testprozesse beginnen mit einem internen Build zur firmen- bzw. teaminternen Prüfung, einer Developer Preview für andere Entwickler*innen verbundener Software, einer Closed und oft einer Public Beta.

Auch die erweiterte Publizierung eines Release Candidates könnte als offene Beta genutzt werden, um eine so gut wie fertiggestellte Version einer größeren Öffentlichkeit zu präsentieren. Ob die Nutzung eines Freigabekandidaten für die eigene Software sinnvoll ist, hängt auch von der Art der Software ab.

Release Candidate in der agilen Softwareentwicklung

In der agilen Softwareentwicklung kommen Release Candidates auch für einzelne Features zur Anwendung, die von Iteration zu Iteration getestet werden, um anschließend in den finalen Release integriert zu werden. Hier bezieht sich der Freigabekandidat oft auch auf einzelne Features einer bestehenden Software, ein Beispiel hierfür wäre etwa das Hostingsystem Drupal.

Drupal nutzt nach einer Beta-Testphase den stabilen, nahezu fertiggestellten Code, um beinahe releasefähige Features einem letzten Test zu unterziehen.

Mit angekündigten Feature Freezes gehen diese in de nächste Release Version über, weitere Änderungen werden dann erst mit dem nächsten stabilen Release nachgereicht.

Vom Release Candidate zum Final Build

Je näher der öffentliche Release einer Software rückt, umso mehr möchten Entwicklerinnen und Entwickler natürlich sicherstellen, dass es zu keinen systemkritischen Bugs mehr kommt. Der RC ist die letzte große Testversion vor der finalen Version und kann entsprechend noch einmal großflächig bestehende Fehler aufdecken.

Im besten Fall (und nach einem langen Beta-Test) ist der Code des Release Candidates mit dem des Final Builds aber (nahezu) identisch und die Developer können die zu vermarkende Release Version vorbereiten.

(ID:47921967)