A release candidate (RC) is a build of software that is feature complete, has passed internal testing and is intended to become the final release unless significant defects are found. In the software lifecycle, it sits between the beta phase and the general availability release, and its purpose is final validation rather than further development.
The defining property of a release candidate is that only critical fixes are allowed after it is cut. If testing reveals a serious bug, the team fixes it and issues the next candidate, such as RC2; if no blocking issue appears within the agreed period, the last candidate is promoted, often bit for bit, to the stable release.
Where the release candidate fits in the lifecycle
Most release processes move through a sequence of pre-release stages, each with a narrower scope of permitted change. The release candidate is the last stage before shipping, which is why it is subject to the strictest change control.
The table below shows the usual stages and what each one allows.
| Stage | Main goal | Changes allowed | Typical audience |
|---|---|---|---|
| Nightly or snapshot | Integration of ongoing work | Anything | Developers |
| Alpha | Early feature testing | New features and redesigns | Internal testers |
| Beta | Broad testing and feedback | Bug fixes, small feature changes | Early adopters |
| Release candidate | Final validation | Critical fixes only | Wide testing, partners |
| General availability | Production use | None until the next patch | All users |
Not every project uses every stage. Small libraries may skip alpha and beta and publish one or two candidates before a release, while large platforms such as operating systems or compilers often run several weekly candidates over a period of one to two months.
How a release candidate is produced and promoted
A release candidate is cut from a stabilization branch or a tagged commit once the feature freeze and usually a string freeze for translations are in effect. From that point, every proposed change must pass a review that asks one question: does it fix a release blocker without introducing new risk?
- The team declares the feature freeze and creates the release branch.
- The build system produces the candidate with the same pipeline that will produce the final release.
- Testers run regression suites, upgrade tests and real-world workloads against the candidate.
- Blocking defects are fixed on the branch, and a new numbered candidate is issued.
- When a candidate survives the soak period without blockers, it is tagged as the final release.
A release blocker is a defect severe enough to stop the release, such as data loss, a security vulnerability, a crash in a core workflow or a broken upgrade path. Cosmetic issues and minor bugs are normally deferred to the first patch release instead of resetting the candidate cycle.
Release candidate naming and version precedence
Naming conventions differ between ecosystems, and the differences matter because package managers sort versions automatically. Under Semantic Versioning, a pre-release label follows a hyphen, as in 2.4.0-rc.1, and any pre-release version has lower precedence than the plain release 2.4.0.
| Ecosystem | Example | Ordering rule |
|---|---|---|
| Semantic Versioning | 2.4.0-rc.1 | Numeric identifiers compare as numbers |
| Python packaging | 2.4.0rc1 | Defined by the version specifier standard |
| Debian packages | 2.4.0~rc1 | The tilde sorts before the release |
| Linux kernel | 6.12-rc3 | Weekly candidates before the final tag |
| Marketing builds | Release Preview, RTM | Not machine-ordered |
A common pitfall is writing rc1 and later rc10 without a dot separator under Semantic Versioning, where alphanumeric identifiers compare character by character, so rc10 sorts before rc2. Using rc.1, rc.2 and rc.10 keeps the numeric comparison correct.
Release candidate compared with neighboring terms
The release candidate is often confused with other milestone names. The distinction lies in what the build promises: a beta promises features, a release candidate promises readiness, and a stable release promises support.
| Term | What it signals | Support expectation |
|---|---|---|
| Beta | Features are present but may change | None, feedback expected |
| Release candidate | Ready to ship unless blockers appear | Limited, for testing |
| Release to manufacturing | Final build handed to production or partners | Prepared for launch |
| General availability | Officially released to everyone | Full support begins |
| LTS release | Stable release with an extended support window | Years of maintenance |
The release candidate also defines the starting point for support planning. Once the candidate becomes the stable release, the clock for end of life dates and later deprecation notices begins, so the quality of the candidate shapes the maintenance burden for the whole support window.
Testing a release candidate and common mistakes
Release candidates are most valuable when people outside the core team run them on realistic systems and data. Integrators, plugin authors and system administrators find problems that automated suites miss, especially upgrade paths, unusual hardware and interactions with third-party software.
- Treating the candidate as a beta: merging new features after the cut restarts the risk that the stage exists to remove.
- Rebuilding for the final release: producing the final binaries from a different pipeline or commit invalidates the testing done on the candidate.
- Running it in production: a candidate carries no support guarantee and may not have a supported upgrade path to the final version.
- Ignoring silence: few bug reports may mean little testing, not high quality, so teams track how many testers actually ran the build.
- Too short a soak period: a few days may miss defects that appear only under sustained load or after scheduled tasks run.
Stripped to the essentials
A release candidate is the version the team thinks is finished. Before calling it final, they hand it to many testers and wait. If someone finds a serious problem, they fix only that problem and try again with a new candidate.
Think of it as the final dress rehearsal before opening night. The script and costumes no longer change; the cast only fixes what would ruin the show. The key takeaway is that a release candidate is for testing, not for everyday reliance.
Where it is applied
An open-source database project plans a new major version. After the beta period, the maintainers declare a feature freeze, cut the release branch and publish 5.0.0-rc.1. They ask hosting providers and application developers to run their test environments on it for three weeks.
During the second week, a hosting provider reports that upgrading a large production copy corrupts one type of index. The maintainers classify it as a release blocker, fix it on the branch and publish 5.0.0-rc.2. Two further weeks pass with only minor reports, which are scheduled for version 5.0.1. The team then tags the exact rc.2 build as 5.0.0, so every tested binary ships unchanged.