Release Candidate: The Final Dress Rehearsal
A Release Candidate (RC) is the final dress rehearsal before a software launch—a version believed to be stable enough to ship. It's used for final validation to catch show-stopping bugs.
WHY IT EXISTS: To de-risk a public software release. Pushing code directly from development to all users is risky. A staged rollout process with checkpoints like Alpha, Beta, and Release Candidate allows teams to build confidence and catch issues before they affect everyone. The RC is the final checkpoint before a full public launch.
THE MENTAL MODEL: A Release Candidate is a promise: "We think this is the final version. Unless a critical bug is found, this exact build will be shipped to everyone." It's a candidate for the "gold" master, the version that gets released. If a critical bug is found, you fix it and issue a new RC (e.g., RC2), restarting the final validation process.
HOW IT WORKS: After a feature-complete beta testing phase, the team selects a stable build and labels it "Release Candidate 1" (RC1). It undergoes rigorous testing focused only on finding "showstoppers"—bugs so severe they would prevent a release. If no showstoppers are found, RC1 is promoted to the final "General Availability" (GA) release. If a showstopper is found, it's fixed, and a new build, "RC2," is created and the process repeats.
WHEN TO USE IT: Use an RC process for any significant software release where stability is critical, such as major versions of desktop software, mobile apps, or backend services. It's a standard part of structured release cycles. For teams practicing continuous deployment, the concept is often replaced by canary releases, which serve a similar risk-reduction purpose.
WHEN NOT TO USE IT: A formal RC process is overkill for trivial changes or hotfixes where risk is low. In a true continuous deployment model where small changes are released multiple times a day, the "RC" phase is effectively compressed into automated testing and gradual rollouts, making the formal label less common.
ONE CANONICAL EXAMPLE: Before a new version of an operating system like iOS is released to the public, Apple first releases one or more Release Candidates to developers. These builds are functionally identical to what they intend to ship. If developers find no major issues, that RC build becomes the public release. If a critical bug is found, a new RC is issued and the cycle repeats.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.