Release Candidate
A software version that is potentially ready for final release, pending the outcome of last-stage testing.
What Is a Release Candidate?
A release candidate, often abbreviated as RC, is a build of the software that the team believes is ready for production but has not yet been formally approved. It represents the final stage of the development cycle before general availability. The code is feature-complete, meaning no new functionality will be added; the only changes permitted are bug fixes discovered during the final round of testing.
Release candidates are typically numbered sequentially. RC1 is the first candidate, and if testing reveals blocking issues, fixes are applied and a new candidate, RC2, is created. This process repeats until a candidate passes all quality gates and is promoted to the official release. The concept is closely related to the staging environment, where the RC is deployed for validation under conditions that mirror production as closely as possible.
Why Release Candidates Matter
The release candidate phase exists to create a controlled window for catching last-minute defects without the pressure of active feature development. By freezing the feature set, the team can focus entirely on stability, performance, and edge cases. This is the stage where beta testing feedback is most actionable, because any issues found can be addressed before the release reaches the general public.
Release candidates also improve communication across the organization. When a product manager sees that the team has cut RC1, they know the release is imminent and can coordinate marketing, documentation, and support preparations. The structured progression from RC1 through final approval gives stakeholders a clear view of release readiness at all times. Understanding the alpha vs beta testing timeline helps contextualize where the release candidate fits in the broader process.
Best Practices
Define explicit criteria for promoting a release candidate. Common gates include zero critical bugs, all automated tests passing, performance benchmarks met, and sign-off from QA and product leads. Without clear criteria, the decision to ship becomes subjective and prone to pressure.
Limit changes between candidates. Every fix applied to an RC introduces risk, so only address issues that are severe enough to block the release. Minor improvements and cosmetic tweaks should be deferred to a subsequent update. Use a feature flag to disable any incomplete or risky functionality rather than removing code.
Test the candidate in the environment where it will actually run. Deploy the RC to a production-like staging environment and run the full regression, performance, and security test suites. Consider a canary release strategy to expose the RC to a small slice of real traffic before the full rollout, providing one last layer of validation.
Document everything. Record what changed between candidates, which tests were run, and who approved the final promotion. This audit trail is invaluable for post-release investigations and for improving the release process over time.