Release candidate (RC): what it means and how to run one
5 min read
A release candidate (RC) is a build that the team believes is ready to ship. It is feature-complete, it has passed the planned testing, and it becomes the final release unchanged unless someone finds a bug serious enough to block it. The label is a promise about the build: no new features, only fixes for blockers. If a fix is needed, the team cuts a new candidate and starts the clock again.
| Stage | Features | Audience | Expected state |
|---|---|---|---|
| Alpha | Still being added | Internal team | Incomplete, many known bugs |
| Beta | Complete or nearly so | Volunteers and selected customers | Usable, bugs expected |
| Release candidate | Frozen | Testers and early adopters | Believed ready, only blockers fixed |
| General availability (GA) | Frozen | Everyone | The same build as the last RC |
What is a release candidate in software?
It is the last pre-release stage before general availability. The idea is that the build is a candidate for the final version, and the release happens by promoting that same build instead of making a new one. Wikipedia’s article on the software release life cycle describes the same sequence of alpha, beta, release candidate and release, and the terms are widely understood across open source projects and vendors.
What is the difference between beta and release candidate?
A beta is still allowed to change. Features can be adjusted, interfaces can move, and the goal is to learn what is missing or wrong. A release candidate has stopped changing in those ways, and the goal is to confirm that nothing blocks the release. The practical test is what the team does with a bug report. In a beta, a report may lead to a design change. In an RC, a report leads to a fix only if the bug blocks shipping, and everything else is queued for the next version.
How do you version a release candidate?
Use a pre-release suffix on the version you are about to ship. Under Semantic Versioning, a hyphen followed by dot-separated identifiers marks a pre-release, so the first candidate for 2.4.0 is 2.4.0-rc.1, the next is 2.4.0-rc.2, and the release is plain 2.4.0.
Precedence follows the spec: 2.4.0-rc.1 sorts below 2.4.0-rc.2, and any pre-release sorts below the release. Because identifiers are compared one by one and numbers compare numerically, rc.10 sorts above rc.9. The alpha, beta and rc names also sort alphabetically in the right order, which is part of why teams use them. Tag each candidate in git, as described in git tags and releases, so the exact commit is recorded.
What are the exit criteria for a release candidate?
Write them down before the first RC is cut. A workable set:
- The automated test suite passes on the exact commit that was built.
- The upgrade path from the previous release was tested with realistic data.
- Known issues are triaged, and none is rated a blocker.
- Performance and error rates match the previous release within an agreed margin.
- The release notes are drafted and reviewed against the final list of changes.
- A rollback path exists and someone has read it.
When every line is true for a candidate, that candidate is the release. If any line fails, the fix produces a new candidate and the checks restart. The seven-step version of this flow, with owners for each step, is in release management process.
What should you do with the build when an RC passes?
Promote the same artifact. Do not rebuild from the tag, because a rebuild can pull in a different dependency or compiler output, and the testing you did applied to the original build. Many teams rename the candidate by re-tagging or re-pointing a registry label, so the bytes that were tested are the bytes users download.
For packages, publish candidates under a separate channel so ordinary users do not receive them by accident. With npm, npm publish --tag rc keeps the default latest tag where it was, and only people who ask for @rc get the candidate. Container images and mobile builds have the same idea under other names: a pre-release tag, a staged rollout or a TestFlight-style track.
How do you write release notes for a release candidate?
Start the notes at the first RC and keep them in step with the candidates. Testers need to know what changed, what to check and what is known to be broken, and drafting early finds the entries nobody remembers at the end. Mark the page or the GitHub release as a pre-release so nobody mistakes it for the final version, and move the finished text to the GA release when it ships. Layout and contents are in software release notes, and the GitHub side is in GitHub release notes.
Do SaaS teams need release candidates?
Teams that deploy continuously rarely do, because the production deploy is the test and a feature flag controls who sees a change. Release candidates earn their place when users install the software themselves and cannot be rolled back with a deploy: libraries, desktop and mobile apps, self-hosted products and APIs with long-lived clients. For a hosted product that exposes changes gradually, the equivalent is a staged rollout, which the article on feature flag release notes covers from the communication side.
FAQ
What does RC mean in software? RC stands for release candidate. It is a build that the team intends to ship as the final version unless testing finds a blocking bug. It follows alpha and beta stages and precedes general availability.
Is a release candidate stable enough for production? Usually yes for testing in a staging or limited production setting, and it carries a risk the final release does not, because testing may not be finished. Treat it as production-quality code that is still on probation.
How many release candidates should a release have? As many as it takes, and most releases need one to three. A long run of candidates usually means the freeze was declared too early or the test coverage is catching things late.
Can a release candidate become the final release without changes? Yes, and that is the intended outcome. The final release should be the same build as the last candidate, only renamed or re-labelled as GA.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.