Release Candidate

Release Candidate – eine Softwareversion, die idealerweise demnächst freigegeben wird

Die Entwicklung einer Software ist weit vorgeschritten. Was noch fehlt, ist ein letzter Blick, ein finales Feedback von ausgewählten Usern und ggf. die Beseitigung kleinerer Fehler, bevor sie für die breite Öffentlichkeit freigegeben wird. Die Version, die kurz vor der Freigabe steht, hat einen Namen: Release Candidate.

Die Idee hinter einem Release Candidate ist es, eine stabile Version einer Software bereitzustellen, die der endgültigen Version so nahe wie möglich kommt. Release Candidates, oftmals mit RC abgekürzt und manchmal auch als Release Kandidat bzw. Freigabekandidat bezeichnet, werden in der Regel an eine ausgewählte Gruppe von Benutzern zum Testen und für Rückmeldungen freigegeben. Der Zweck dieser Tests ist es, in letzter Minute Probleme oder Fehler zu finden, die während des Entwicklungsprozesses übersehen wurden.¹

Wo liegen die Unterschiede zwischen Beta-Version und Release Candidate?

Die Softwareentwicklung kennt verschiedene Entwicklungsstadien wie Pre-Alpha-Version, Alpha-Version, Beta-Version, Release Candidate und Release. Ein wesentlicher Unterschied zwischen einem Release Candidate und einer Beta-Version besteht darin, dass eine RC-Version im Grunde eine endgültige Version der Software ist, während sich eine Beta-Version noch in der Testphase befindet. Beta-Versionen werden oftmals einer größeren Gruppe von Benutzern zum Testen und für Rückmeldungen zur Verfügung gestellt, während RC-Versionen nur einer kleineren Gruppe von Testern zugänglich gemacht werden, die häufig bereits Erfahrungen mit der Software haben.

Ein weiterer Unterschied zwischen Release Candidates und Beta-Versionen besteht darin, dass Freigabekandidaten üblicherweise mit allen Funktionen ausgestattet sind, die später auch im Release zur Verfügung stehen. Im Gegensatz dazu können in Beta-Versionen noch einige Funktionen fehlen oder unvollständig sein.

User, die ein Release Candidate testen, erwarten daher in der Regel eine stabile Version der Software, die sehr nahe an der endgültigen Version ist. Sie können auf einige kleinere Probleme oder Fehler stoßen, die aber in der Regel nicht so schwerwiegend sind und sich daher zügig beseitigen lassen, sodass sie die Freigabe der Software nicht ernsthaft verzögern. Entsprechend werden Benutzer gebeten, alle Probleme zu melden, auf die sie stoßen, damit sie vor der endgültigen Veröffentlichung behoben werden können.²

Die Interaktion zwischen Hersteller und Benutzer

Die Verwendung von Release Candidates im Rahmen des Softwareentwicklungsprozesses kann sich positiv auf das Image der Benutzer auswirken. Benutzer, die an RC-Tests teilnehmen, fühlen sich häufig wertgeschätzt und in den Entwicklungsprozess einbezogen. Sie haben die Möglichkeit, Feedback zu geben und Verbesserungen vorzuschlagen, was oft dem Produkt bzw. der Qualität zu Gute kommt. So entsteht schnell ein Gefühl der Gemeinschaft und Partnerschaft zwischen den Benutzern und dem Entwicklungsteam. Zudem kann die Verwendung von Freigabekandidaten dazu beitragen, dass die Software nicht negativ wahrgenommen, kommentiert oder bewertet wird, wenn nach der Veröffentlichung Probleme auftreten.

Es ist jedoch zu beachten, dass die Verwendung von Release Candidates mit einigen Risiken verbunden ist. Wenn ein RC zu früh oder ohne ordnungsgemäße Tests veröffentlicht wird, kann er erhebliche Fehler oder Probleme aufweisen, die unter Umständen dem Image des Herstellers schaden. Daher ist es wichtig, Release Candidates mit Bedacht einzusetzen und sicherzustellen, dass sie vor der Freigabe gründlich getestet werden.³

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Im Zuge der Verwendung von Freigabekandidaten wird ab und an auch von “Gamma Delta” gesprochen. Gamma-Tests folgen in der Regel auf Beta-Tests und gehen der endgültigen Freigabe einer Software voraus. “Delta-Debugging” bezieht sich auf eine Technik, bei der iterativ Teile eines Programms isoliert werden, um Code zu identifizieren, der einen Bug verursacht.
[2] Entscheidet sich ein Unternehmen kleinere Fehler vor der Freigabe der Software zu fixen, sollte dringend eine neue Version – ein RC1, RC2 usw. – erstellt und entsprechend getestet werden. Unternehmen, die von einer solchen Praktik abweichen, tun sich mittelfristig meist keinen Gefallen, wenn sie verschiedene Versionsstände unter einem gemeinsamen Label betreiben.
[3] In manchen Publikationen ist zu lesen, dass es nicht “schlimm” sei, wenn in Freigabekandidaten schwerwiegende Fehler entdeckt würden, die nicht zu einem Bugfixing vor der Softwarefreigabe führen, da Unternehmen häufig in der Lage wären, entsprechende Probleme durch die Bereitstellung von Patches oder Hotfixes zu beseitigen. Doch nur weil es Unternehmen gibt, die in der Praxis das Bananenprinzip nutzen, heißt dies nicht, dass dies so sein sollte. Eine Software, die schwerwiegende Fehler aufweist oder erst bei Anwendern reift, kann kurzfristig Schaden bei den Anwendern verursachen oder zukünftige Verwendungen gefährden.

Im Allgemeinen wird Unternehmen empfohlen, die endgültige Versionsfreigabe abwarten, bevor sie eine neue Software in einer Produktionsumgebung einsetzen. In bestimmten Situationen, in denen Dringlichkeit, begrenzte Änderungen oder ein hohes Maß an Vertrauen vorhanden sind, gilt die Bereitstellung eines Release Candidates in der Produktion aber als temporär praktikable Option.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt: