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.
Kurz vor der finalen Veröffentlichung einer Software dienen Release Candidates dazu, letzte Fehler aus der Welt zu schaffen.
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.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
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.