Release candidate (RC): wat het is en hoe je er een draait
5 min lezen
Een release candidate (RC) is een build waarvan het team gelooft dat die klaar is om uit te brengen. Hij is feature-compleet, heeft de geplande tests doorstaan en wordt ongewijzigd de definitieve release, tenzij iemand een bug vindt die ernstig genoeg is om hem te blokkeren. Het label is een belofte over de build: geen nieuwe features, alleen fixes voor blokkades. Is een fix nodig, dan maakt het team een nieuwe kandidaat en begint de klok opnieuw.
| Fase | Features | Doelgroep | Verwachte staat |
|---|---|---|---|
| Alfa | Worden nog toegevoegd | Intern team | Onvolledig, veel bekende bugs |
| Bèta | Compleet of bijna | Vrijwilligers en geselecteerde klanten | Bruikbaar, bugs verwacht |
| Release candidate | Bevroren | Testers en early adopters | Naar verwachting klaar, alleen blokkades gefixt |
| General availability (GA) | Bevroren | Iedereen | Dezelfde build als de laatste RC |
Wat is een release candidate in software?
Het is de laatste pre-releasefase voor general availability. Het idee is dat de build een kandidaat is voor de definitieve versie, en dat de release plaatsvindt door diezelfde build te promoten in plaats van een nieuwe te maken. Het Wikipedia-artikel over de software release life cycle beschrijft dezelfde reeks van alfa, bèta, release candidate en release, en de termen worden breed begrepen in open-sourceprojecten en bij leveranciers.
Wat is het verschil tussen bèta en release candidate?
Een bèta mag nog veranderen. Features kunnen worden bijgesteld, interfaces kunnen verschuiven, en het doel is te leren wat er mist of fout is. Een release candidate is op die manieren gestopt met veranderen, en het doel is bevestigen dat niets de release blokkeert. De praktische toets is wat het team met een bugmelding doet. In een bèta kan een melding tot een ontwerpwijziging leiden. In een RC leidt een melding alleen tot een fix als de bug het uitbrengen blokkeert, en al het andere gaat in de wachtrij voor de volgende versie.
Hoe versioneer je een release candidate?
Gebruik een pre-releasesuffix op de versie die je gaat uitbrengen. Onder Semantic Versioning markeert een koppelteken gevolgd door identifiers gescheiden door punten een pre-release, dus de eerste kandidaat voor 2.4.0 is 2.4.0-rc.1, de volgende is 2.4.0-rc.2 en de release is gewoon 2.4.0.
De rangorde volgt de specificatie: 2.4.0-rc.1 sorteert onder 2.4.0-rc.2, en elke pre-release sorteert onder de release. Omdat identifiers een voor een worden vergeleken en getallen numeriek, sorteert rc.10 boven rc.9. De namen alpha, beta en rc sorteren ook alfabetisch in de juiste volgorde, wat een reden is dat teams ze gebruiken. Tag elke kandidaat in git, zoals beschreven in git tags en releases, zodat de exacte commit is vastgelegd.
Wat zijn de exitcriteria voor een release candidate?
Schrijf ze op voordat de eerste RC wordt gemaakt. Een werkbare set:
- De geautomatiseerde testsuite slaagt op de exacte commit die is gebouwd.
- Het upgradepad vanaf de vorige release is getest met realistische data.
- Bekende problemen zijn getrieerd en geen enkel is als blokkade beoordeeld.
- Prestaties en foutpercentages komen binnen een afgesproken marge overeen met de vorige release.
- De release notes zijn opgesteld en gecontroleerd aan de hand van de definitieve lijst met wijzigingen.
- Er bestaat een terugdraaipad en iemand heeft het gelezen.
Als elke regel waar is voor een kandidaat, is die kandidaat de release. Faalt een regel, dan levert de fix een nieuwe kandidaat op en beginnen de controles opnieuw. De versie met zeven stappen van deze flow, met eigenaren per stap, staat in releasemanagementproces.
Wat doe je met de build als een RC slaagt?
Promoot hetzelfde artefact. Bouw niet opnieuw vanaf de tag, want een nieuwe build kan een andere dependency of compileruitvoer binnenhalen, en de tests die je deed golden voor de oorspronkelijke build. Veel teams hernoemen de kandidaat door opnieuw te taggen of een registrylabel om te zetten, zodat de bytes die zijn getest de bytes zijn die gebruikers downloaden.
Publiceer kandidaten voor pakketten onder een apart kanaal, zodat gewone gebruikers ze niet per ongeluk krijgen. Met npm laat npm publish --tag rc de standaardtag latest waar die was, en alleen mensen die om @rc vragen krijgen de kandidaat. Containerimages en mobiele builds kennen hetzelfde idee onder andere namen: een pre-releasetag, een gefaseerde uitrol of een TestFlight-achtig spoor.
Hoe schrijf je release notes voor een release candidate?
Begin met de notes bij de eerste RC en houd ze gelijk met de kandidaten. Testers moeten weten wat er veranderde, wat ze moeten controleren en wat bekend kapot is, en vroeg opstellen vindt de items die aan het eind niemand meer weet. Markeer de pagina of de GitHub-release als pre-release, zodat niemand hem voor de definitieve versie aanziet, en verplaats de afgewerkte tekst naar de GA-release zodra die uitkomt. Opmaak en inhoud staan in software release notes, en de GitHub-kant in GitHub release notes.
Hebben SaaS-teams release candidates nodig?
Teams die continu deployen hebben ze zelden nodig, omdat de productiedeploy de test is en een feature flag bepaalt wie een wijziging ziet. Release candidates verdienen hun plek als gebruikers de software zelf installeren en niet met een deploy kunnen worden teruggedraaid: bibliotheken, desktop- en mobiele apps, zelf gehoste producten en API’s met langlopende clients. Voor een gehost product dat wijzigingen geleidelijk blootstelt is het equivalent een gefaseerde uitrol, die het artikel over release notes bij feature flags vanuit de communicatiekant behandelt.
FAQ
Wat betekent RC in software? RC staat voor release candidate. Het is een build die het team als definitieve versie wil uitbrengen, tenzij testen een blokkerende bug vindt. Hij volgt op de alfa- en bètafase en gaat vooraf aan general availability.
Is een release candidate stabiel genoeg voor productie? Meestal ja voor testen in een staging- of beperkte productieopzet, en hij draagt een risico dat de definitieve release niet heeft, omdat het testen mogelijk nog niet klaar is. Behandel hem als code van productiekwaliteit die nog op proef is.
Hoeveel release candidates moet een release hebben? Zoveel als nodig, en de meeste releases hebben er een tot drie nodig. Een lange reeks kandidaten betekent meestal dat de freeze te vroeg werd uitgeroepen of dat de testdekking dingen laat vangt.
Kan een release candidate zonder wijzigingen de definitieve release worden? Ja, en dat is de bedoelde uitkomst. De definitieve release hoort dezelfde build te zijn als de laatste kandidaat, alleen hernoemd of opnieuw gelabeld als GA.
De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.