A release candidate is the version a software team believes could become the final public release, if no serious bugs are found. It comes after alpha and beta testing, when features are frozen and the product is being checked for stability, security, and polish. A beta may still change a lot. A release candidate should not.
TLDR: A release candidate, often called an RC, is a near-final build sent out for final testing before launch. For example, a mobile app team might ship Version 3.0 RC1 to 5,000 testers and approve it for release if crash rates stay under 0.5% for seven days. Beta versions are broader test builds with known rough edges. RC builds are supposed to prove that the software is ready for real users.
What Does Release Candidate Mean?
A release candidate is a software build that has passed earlier testing stages and is being considered for final release. The word candidate matters. It is not automatically the final version. It is a final-version hopeful.
At this stage, the team usually stops adding features. Developers focus on fixing serious bugs, checking performance, reviewing installation flows, and confirming that documentation matches the product. If the RC passes these checks, it may be renamed as the official release with little or no code change.
The catch is that “release candidate” can mean slightly different things across companies. Some teams treat RCs with strict discipline. Others use the label too early, which drives testers a bit mad when “almost final” still crashes during login.
Release Candidate vs Beta: The Core Difference
The main difference is confidence. A beta version asks, “Does this work well enough for wider testing?” A release candidate asks, “Is this good enough to ship?”
- Beta: Features may still change. Bugs are expected. Feedback may affect design, performance, and workflows.
- Release Candidate: Features are locked. Only high-priority fixes should be made. The goal is final approval.
Beta testing is often used to catch usability problems, edge cases, device issues, and integration failures. A beta user might report that a settings screen is confusing or that a payment flow takes 12 seconds longer than expected.
An RC test is stricter. Testers look for blockers, regressions, broken upgrades, security issues, and anything that would make the launch unsafe. Minor text issues may be logged, but they may not block release.
Common Software Release Stages
Most software follows a staged release process. The names vary, but the pattern is familiar.
1. Pre Alpha
Pre alpha is the earliest working phase. The product may be incomplete, unstable, or partly experimental. Developers are still building the foundation. Many features may exist only as rough prototypes.
This stage is usually internal. It is used by engineers, product managers, and designers to check whether the core idea can work.
2. Alpha
Alpha software has more structure, but it is still early. Key features are being implemented. Bugs are common. Performance may be poor. Interfaces may change from one build to the next.
Alpha testing is often done inside the company or with a small trusted group. The goal is not perfection. The goal is to find major problems before wider testing begins.
3. Beta
Beta is a more usable version shared with a larger group. It may be public or private. A private beta limits access to selected testers. A public beta allows a much wider audience to try the software.
Beta versions help teams discover real-world issues. These may include slow startup times, confusing menus, missing accessibility support, or crashes on specific devices. Honestly, it feels like every beta finds at least one bug that nobody saw in the lab.
4. Release Candidate
Release candidate comes after beta, once the team believes the product is nearly done. It should include all planned features, final interface behavior, and completed core documentation.
If a major bug appears, the team fixes it and creates another RC. That version may be called RC2, then RC3, and so on. Each new RC restarts final validation.
5. General Availability
General availability, or GA, is the official public release. This is the version promoted to customers, listed in app stores, published on download pages, or deployed to production systems.
GA does not mean bug-free. No serious team claims that. It means the software has met the release standard and is supported for normal use.
6. Stable Release
A stable release is a version considered safe for regular use. In many projects, stable and GA mean almost the same thing. In open source projects, “stable” may contrast with nightly, beta, or development builds.
7. Patch or Maintenance Release
After launch, teams publish patch releases to fix bugs, security issues, or performance problems. These are often numbered like 2.1.1 or 4.0.2. They usually avoid major feature changes.
How Release Candidate Numbering Works
Release candidates are often numbered in sequence:
- RC1: The first build believed to be ready for final release.
- RC2: A second candidate after fixes from RC1.
- RC3: A later candidate if more critical fixes were needed.
If RC1 passes, it may become the final release. If RC1 fails because of a serious issue, the team fixes the issue and creates RC2. This continues until the build meets the release bar or the launch is delayed.
What Testers Check in a Release Candidate
RC testing is less about new feedback and more about risk control. Testers usually check:
- Critical user flows: login, checkout, saving, exporting, installation, updates.
- Regression bugs: features that worked before but broke after recent changes.
- Performance: load times, memory use, battery drain, server response times.
- Security: permission issues, exposed data, authentication problems.
- Compatibility: browsers, operating systems, devices, plugins, APIs.
- Upgrade paths: clean installs and updates from older versions.
For example, a desktop app RC may be tested on Windows 10, Windows 11, macOS Sonoma, and several Linux distributions. If the installer fails on one major system, the RC should not ship.
When Is a Release Candidate Ready to Become Final?
An RC can become final when it meets clear release criteria. A team may require zero blocker bugs, no critical security issues, successful upgrade tests, acceptable crash rates, and sign-off from engineering, product, QA, and support.
Some teams also use analytics. A web platform might require 99.9% successful deployments in staging, page load times under two seconds for key pages, and no more than one severe error per 10,000 sessions during RC testing.
Minor issues may remain if they do not harm core use. A typo in a help tooltip may wait. A broken password reset cannot.
Why Release Candidates Matter
Release candidates reduce launch risk. They give the team a final checkpoint before software reaches everyone. This matters most when the product handles payments, business data, health records, customer communication, or large user bases.
Skipping the RC stage can save a few days, but it may cost far more later. A rushed release can lead to emergency patches, angry users, bad reviews, and support queues that take weeks to clear.
FAQ
What is a release candidate in simple terms?
A release candidate is a near-final version of software. It may become the official release if no serious problems are found.
Is a release candidate safe to use?
It is usually safer than a beta, but it is still not guaranteed final. For critical work, a stable or GA release is usually the better choice.
Is beta earlier than release candidate?
Yes. Beta comes before the release candidate stage. Beta testing gathers broader feedback, while RC testing checks final readiness.
Can there be more than one release candidate?
Yes. If RC1 has major bugs, the team may create RC2, RC3, or more until the software passes final checks.
Does release candidate mean feature complete?
In most cases, yes. A release candidate should be feature complete. New features at this stage can create fresh bugs and delay launch.
What comes after a release candidate?
If the RC passes testing, it becomes the final release, stable release, or general availability version. If it fails, another RC is created.
Published on September 16, 2026 under .
