What Is a Software Release Candidate?

A single bug in production cost Knight Capital Group $440 million in under an hour. The release candidate phase exists to prevent exactly that kind of disaster.

So what is a software release candidate, and why does it sit between beta testing and the final stable release? It’s the last build a team tests before shipping to users. If nothing critical breaks, that build becomes the version everyone downloads.

This article covers how release candidates work within the software development lifecycle, how they differ from beta and stable builds, how versioning conventions like RC1 and RC2 apply, what testing happens during the RC phase, and when (if ever) you should run one in production.

What Is a Software Release Candidate

A software release candidate (RC) is a pre-release version of a product that could become the final build if no critical bugs are found. It sits at the tail end of the software release cycle, right after beta testing wraps up.

The RC is feature-complete. No new functionality gets added at this stage. The only changes allowed are fixes for showstopper-class bugs that would block a production launch.

Think of it as the last checkpoint before general availability (GA). If the build passes final validation, it ships. If something breaks, a new RC gets cut (RC2, RC3, and so on) and the clock resets.

Wikipedia’s entry on the software release life cycle defines it as a beta version with the potential to become a stable product, ready for release unless significant bugs surface. All features have been designed, coded, and tested through one or more beta cycles at this point.

The term “release candidate” shows up across software development broadly. You’ll see it in open-source projects like the Linux kernel, in commercial tools from JetBrains and Microsoft, and across package managers like npm, pip, and Maven. The label is the same everywhere: this build is potentially the one.

Why the RC Exists

Catching bugs after launch is expensive. IBM’s Systems Sciences Institute found that fixing a defect after product release costs 4 to 5 times more than catching it during design, and up to 100 times more in the maintenance phase.

The RC phase exists to compress that risk into a controlled window. Teams run regression tests, integration checks, and user acceptance testing against a frozen codebase to catch anything that slipped through beta.

According to CISQ, poor software quality cost U.S. companies an estimated $2.41 trillion in 2022. A big chunk of that comes from bugs reaching production that could have been caught earlier. The release candidate stage is specifically designed to prevent that.

Where a Release Candidate Fits in the Software Development Lifecycle

Every piece of software moves through stages before users get their hands on it. The RC occupies a specific slot in that sequence, and getting confused about where it sits leads to bad decisions about what testing to run and when.

The Standard Progression

The move from beta to RC happens when the team declares a feature freeze. No more new code goes in. Only bug fixes that clear a severity threshold.

The Linux kernel follows this pattern precisely. After a two-week merge window closes, Linus Torvalds releases weekly RC snapshots (typically RC1 through RC7) over a 7-week stabilization period. Linux 6.11-rc1 alone contained over 12,000 commits, with the majority being driver updates and architecture fixes (kernel.org).

What Triggers the Transition

Teams don’t just decide “it feels ready.” There’s usually a bug triage process with clear thresholds.

Zero showstopper bugs: No defects that would prevent core functionality from working.

Regression pass rate: Automated regression testing hits an agreed coverage percentage with no new failures.

Stakeholder sign-off: Product owners and QA leads formally agree the build is ready for RC status.

The 2024 DORA State of DevOps Report surveyed over 39,000 professionals and found that only 19% of teams reached elite-level delivery performance, with lead times under a day and failure rates around 5%. Most teams operate at medium or low levels, which makes the structured RC phase even more important as a quality gate.

How a Release Candidate Differs from Beta and Stable Builds

People mix these up constantly. “Is the RC basically a late beta?” No. “Is it the same as the final release?” Also no. The differences matter for how you test, what you report, and whether you should run it on anything you care about.

RC vs. Beta

A beta build is still collecting feedback on features. Things might change. Entire UI flows could get reworked. Known bugs are expected and documented.

An RC is past all that. The feature set is locked. The only question left is: “Did we miss anything critical?”

Code changes in beta: Feature additions, refactoring, performance tuning, bug fixes of all severities.

Code changes in RC: Only showstopper bug fixes. Everything else waits for the next version.

CloudQA’s 2025 analysis noted that 68% of users abandon an app after encountering just two bugs. That stat explains why the RC phase is so conservative about what gets merged. One rushed fix could introduce something worse.

RC vs. Stable Release

A stable release (also called GA, or general availability) is the RC that passed all checks. Sometimes the RC build is literally bit-for-bit identical to the final release. Other times, minor metadata changes get made (build numbers, timestamps) but the actual code is the same.

The key difference is the label and the commitment behind it. When a team ships a stable release, they’re saying: “We stand behind this build for production use.” An RC is saying: “We think this is ready, but we need your help confirming.”

Why Some Projects Skip the RC Label

Not everyone uses the term “release candidate.” Google Chrome, for instance, runs a channel-based system: Canary, Dev, Beta, Stable. There’s no formal RC label, but the late-beta builds function the same way.

VS Code ships monthly with no public RC phase. Continuous deployment pipelines and feature flagging let teams like this run the equivalent of RC testing behind the scenes without exposing a separate build to users.

Rolling release models and DevOps practices have made the formal RC less visible in some workflows. But the concept still exists. Somebody, somewhere, is running a “last check” build before code hits production.

How Release Candidates Are Versioned and Named

Version numbers tell you things if you know how to read them. RC tags follow specific patterns depending on the project, the ecosystem, and the semantic versioning standard the team uses.

Common Naming Patterns

SemVer format: 1.0.0-rc.1 — This follows the Semantic Versioning 2.0 spec. The hyphen and “rc” label mark it as a pre-release.

Dash format: 1.0-RC1, 1.0-rc2 — Common in Java ecosystems and Apache projects.

Kernel format: 6.11-rc1 through 6.11-rc7 — The Linux kernel’s convention, where the number after “rc” indicates which candidate this is.

MoldStud research from 2024 found that nearly 70% of the most-downloaded npm libraries follow semantic versioning rules. RC tags in npm look like 1.2.0-rc.1, and package managers treat them as pre-release by default, meaning they won’t install unless you explicitly request them.

What Multiple RCs Signal

If a project ships RC1, that’s normal. RC2 means they found something worth fixing. RC3 starts raising eyebrows.

By RC5 or RC6, something went wrong earlier in the process. Either the beta phase didn’t catch enough, the code wasn’t actually frozen when it should have been, or scope crept in during stabilization.

The Linux kernel usually wraps up at RC7. Linus Torvalds has occasionally pushed to RC8 or beyond, but that’s the exception. Most mature projects target 2-3 RCs before the final release.

How Package Managers Handle RC Versions

This is a detail that trips people up.

• npm: Running npm install package-name skips RC versions. You need npm install package-name@1.0.0-rc.1 to get one explicitly.
• pip: Same behavior. Pre-release versions require the --pre flag.
• Maven: RC versions sort below stable releases in dependency resolution.

This default exclusion exists for a reason. RC builds aren’t guaranteed stable. Your build pipeline shouldn’t pull them in automatically unless you’ve made a deliberate choice to test against pre-release code.

What Happens During Release Candidate Testing

The RC phase is not “more beta testing.” It has a different purpose, different scope, and different rules about what counts as a blocking issue.

Testing Activities in the RC Phase

Teams run several types of software testing against the RC build, but the focus shifts from discovery to confirmation.

Regression testing: Does everything that worked in beta still work? Automated test suites run against the full software system to catch anything that broke.

Integration testing: Do all components play nice together in the final configuration? API endpoints, database connections, third-party services.

User acceptance testing (UAT): Does the build meet the acceptance criteria defined in the requirements?

DEV Community data from 2024 showed that developers spend roughly 20% of their time fixing bugs, costing about $20,000 per year per developer in the U.S. alone (VentureBeat). The RC phase is where you try to keep that number from getting worse post-launch.

Who Tests a Release Candidate

It depends on the project.

For commercial software, the QA engineer team runs the show. They own the software test plan, execute the test cases, and make the go/no-go recommendation.

Open-source projects do it differently. WordPress publishes RC builds and asks the community to test them. Ubuntu does the same with its release candidates before each version ships. The Linux kernel’s RC snapshots go out to developers and enthusiasts who compile from source and report bugs back to maintainers.

Some companies practice “dogfooding,” where internal teams use the RC in their own workflows. It’s real-world validation without the risk of exposing untested code to paying customers. Luke Chen’s 2024 analysis on release engineering noted that firms collect both internal and external feedback during the RC phase to maximize coverage.

Bug Severity During RC

Not every bug found during RC testing delays the release. Teams classify issues by severity, and only the top tier blocks things.

The defect tracking process during RC is strict. Every reported issue gets triaged fast. If it’s not a showstopper, it goes into the backlog for the next version.

When a Release Candidate Becomes the Final Release

The promotion from RC to stable isn’t automatic. Somebody has to make the call, and the criteria for that decision vary based on the team, the product, and how much is at stake.

The Go/No-Go Decision

“No showstopper bugs” is the baseline requirement. But in practice, the decision involves more than just a clean bug list.

Test coverage thresholds: Has the automated suite achieved the agreed code coverage percentage? Are all critical paths tested?

Performance benchmarks: Does the RC meet software reliability and scalability targets under expected load?

Stakeholder sign-off: Product owners, QA leads, and sometimes legal or compliance teams formally approve the build.

Aspire Systems reported in 2024 that 40% of companies experience at least one critical software failure every quarter. That’s with existing QA processes in place. Skipping or rushing the RC sign-off is a fast way to join that statistic.

What Happens When a Bug Is Found

If a showstopper surfaces during RC testing, the fix goes through the normal software development process on an accelerated timeline. The fix gets merged, a new RC build is cut (RC2, RC3), and the testing clock restarts.

This is where the change management discipline matters. Every fix that goes into an RC needs review, testing, and approval. No cowboy commits at this stage.

Knight Capital Group learned this the hard way in 2012. A software defect in their trading system caused $440 million in losses in under an hour, eventually leading to the company’s collapse. The bug slipped past their release process.

When RC Equals the Final Build

Sometimes the last RC is identical to the stable release. The build artifact is the same binary. The team just changes the version label and publishes it.

Other times, minor changes happen between the last RC and GA. Updated software documentation, license files, or build metadata. The actual executable code stays the same, but the packaging around it might shift slightly.

Either way, once software validation is complete and sign-off happens, the RC graduates. It goes from “candidate” to “the real thing,” and the app deployment process begins.

Release Candidates in Open Source vs. Commercial Software

The RC concept is universal but the execution looks completely different depending on who’s building the software and who’s testing it.

Open-source projects publish their RCs publicly. Anyone can download, test, and file bugs. Commercial teams keep their RCs behind closed doors with internal QA handling everything.

Open-Source RC Practices

Linux kernel: Linus Torvalds releases weekly RC snapshots (typically 7 rounds) after the merge window closes. Each RC contains thousands of commits and gets tested by developers worldwide who compile from source.

WordPress: The 6.7 release in 2024 went through five release candidates (RC1 through RC5) before shipping on November 12. WordPress even doubled their HackerOne bug bounty reward during the RC phase to motivate security researchers.

Python and PHP: Both publish pre-release versions to PyPI and PECL respectively, letting library maintainers test compatibility before the stable version drops.

The strength of community-driven RC testing is coverage. Thousands of people running the same build across different hardware, operating systems, and configurations catches things no internal QA team could find alone.

Commercial Software RC Practices

Microsoft stopped using “release candidate” as a public label after Windows 8. Their pre-release builds now go through the Windows Insider Program as “Insider Preview builds” (Wikipedia).

Apple used “Golden Master” (GM) for years as their equivalent of an RC. Starting with iOS/iPadOS 14.2, they switched to calling it “Release Candidate” instead (The iPhone Wiki).

JetBrains publishes Early Access Program (EAP) builds for tools like IntelliJ IDEA and WebStorm. These function as public RCs where developers test against their own projects before the stable release ships.

Cortex’s 2024 State of Software Production Readiness survey found that 62% of organizations saw increases in change failure rate when production readiness processes weren’t followed consistently. Commercial teams tend to formalize their RC process more because the stakes are higher when paying customers are involved.

How Release Notes Differ

Open-source technical documentation during the RC phase is usually more transparent. You can see every commit, every bug report, every discussion. Commercial projects keep that information internal until the release is finalized.

Common Problems with Release Candidates

The RC phase sounds straightforward on paper. In practice, teams run into the same problems over and over.

Scope Creep During Code Freeze

The most common one. A product manager spots a “small” fix they want squeezed in. A developer notices something “quick” to clean up. Before you know it, the RC contains changes that never went through proper testing.

Every unplanned change during code freeze adds risk. Aspire Systems data shows teams spend 30-50% of sprint cycles fixing defects instead of building features when quality processes break down. That’s exactly what happens when RC discipline slips.

Too Many Release Candidates

RC1 is fine. RC2 means something got caught. RC3 and beyond signal a deeper issue.

When a project churns through RC4, RC5, RC6, it usually means one of these things:

• Beta testing didn’t catch enough
• The code wasn’t actually frozen when the team said it was
• Fixes are introducing new regressions

WordPress 6.7 hitting RC5 was unusual for the project. Each extra RC means more time, more testing cycles, and delayed post-deployment maintenance planning for the next release.

Treating RCs as Production-Ready

This happens more than it should. A client sees “release candidate” and thinks “close enough.” An internal team deploys the RC to a staging server and then quietly starts routing real traffic to it.

Cortex’s 2024 survey showed 52% of respondents have seen software not ship on time due to production readiness failures. Running an RC in production without proper rollback plans is a fast path to that statistic.

Compressed Testing Windows

The pattern: Development runs late. Beta gets cut short. The RC phase gets squeezed into days instead of weeks.

IBM’s Systems Sciences Institute research remains relevant here. Fixing a bug found in production costs up to 100 times more than catching it during design. A compressed RC window doesn’t save time. It shifts the cost to after launch, where it hurts more.

Should You Use a Release Candidate in Production

Short answer: no. Longer answer: probably still no, but there are exceptions.

The General Rule

RCs exist for testing. They’re labeled as pre-release for a reason. Package managers like npm, pip, and Maven deliberately exclude them from default installations.

Running an RC in a production environment means accepting the risk that a showstopper bug still exists in the build. You’re gambling that whatever the RC phase was designed to catch has already been caught.

CloudQA’s 2025 research found that 88% of users are less likely to use a company’s app after a bad experience. Deploying an RC to production and hitting a bug means your users are doing your final testing for you. That’s a bad trade.

When It Makes Sense

There are specific situations where running an RC is justified.

Plugin and extension developers: If you build WordPress plugins, you need to test against the RC before the stable version ships. WordPress explicitly asks plugin authors to update their “Tested up to” version during the RC phase.

Compatibility testing: Teams building on top of frameworks or platforms (like Android SDK or .NET) test against RCs to prepare for breaking changes.

Internal staging environments: Running the RC in a staging setup that mirrors production is standard practice. That’s different from exposing real users to it.

Risk Assessment

If you’re thinking about deploying an RC, ask yourself these questions:

• Do you have a blue-green deployment or canary deployment setup to limit blast radius?
• Can you roll back to the previous stable version in minutes?
• Is your test plan thorough enough to cover critical user flows?

If the answer to any of those is “no,” stay on the stable release. The risk assessment matrix for an RC in production almost never justifies it unless you have proper infrastructure in place.

Release Candidate vs. Other Pre-Release Labels

The RC isn’t the only pre-release label you’ll see. Different companies and ecosystems use different terms, and they don’t all mean the same thing.

Quick Comparison

Golden Master vs. Release Candidate

Apple used “Golden Master” for years as their final pre-release label. The term comes from the music industry, where the “gold master” was the final disc sent for mass duplication.

Starting with iOS/iPadOS 14.2 in 2020, Apple replaced “GM” with “Release Candidate.” Same concept, clearer terminology. The GM build was almost always identical to the public release, just like the last RC typically is for other projects.

RTM vs. Release Candidate

Release to Manufacturing (RTM) is a Microsoft term that means something slightly different. RTM, or “going gold,” indicates the final build has been approved and is being packaged for distribution.

An RC is a candidate for that status. RTM is the confirmation that the candidate passed. Since Windows 8, Microsoft has largely moved away from both terms publicly, using “Insider Preview” for pre-release builds instead.

Why the Label Matters Less Than the Process

Google Chrome uses “Canary, Dev, Beta, Stable.” Firefox uses “Nightly, Developer Edition, Beta, Release.” Neither uses the RC label, but both run equivalent validation processes before their stable builds ship.

What matters is whether the team has a structured approach to the software testing lifecycle at the end of the development cycle. The label is just a name. The software quality assurance process behind it is what actually prevents bugs from reaching users.

Teams following software development best practices run some version of an RC phase regardless of what they call it. Whether it’s a formal release candidate, a golden master, or a “final beta,” the purpose is the same: one last check before the build hits the real world.

FAQ on What Is A Software Release Candidate

What does release candidate mean in software development?

A release candidate (RC) is a pre-release build that could become the final version if no critical bugs are found. It’s feature-complete, code-frozen, and represents the last testing phase before general availability.

How is a release candidate different from a beta version?

A beta build still collects feature feedback and expects known issues. An RC is past that stage. Only showstopper bugs get fixed during the RC phase. Everything else waits for the next version.

What do RC1, RC2, and RC3 mean?

These numbers indicate how many candidate builds have been tested. RC1 is the first attempt. RC2 means a critical bug was found and fixed. Multiple RCs signal the build needed additional rounds of validation.

Can you use a release candidate in production?

Generally, no. RCs are for testing, not production deployment. Package managers like npm and pip exclude them by default. Only use an RC in production if you have proper rollback plans and isolated infrastructure.

How long does the release candidate phase last?

It varies by project. The Linux kernel runs weekly RC snapshots over roughly 7 weeks. WordPress typically takes 2-3 weeks. Commercial teams often compress this into days depending on their release schedule.

What is the difference between a golden master and a release candidate?

Apple used “Golden Master” (GM) as their RC equivalent until iOS 14.2, when they switched to “Release Candidate.” Same concept, different label. Both represent the potentially final build before public release.

Who tests a release candidate?

Internal QA teams handle it for commercial software. Open-source projects like WordPress and the Linux kernel publish RCs publicly so community members, plugin developers, and enthusiasts can test and report bugs.

What happens if a bug is found in a release candidate?

If it’s a showstopper, the team fixes it and cuts a new RC (RC2, RC3). Testing restarts on the new build. Minor bugs get logged and deferred to the next release cycle instead.

How does semantic versioning handle release candidates?

Under SemVer 2.0, RCs use a hyphen and pre-release tag like 1.0.0-rc.1. This tells package managers the build is pre-release. It won’t install by default unless explicitly requested by the developer.

Is a release candidate the same as the final release?

Sometimes, yes. If the last RC passes all checks, it can ship as the stable version with no code changes. Only metadata like version labels or build timestamps might differ between the final RC and the GA build.

Conclusion

Understanding what is a software release candidate comes down to one thing: it’s the last quality gate before your code reaches real users. Skip it, rush it, or treat it casually, and you’re shipping risk straight to production.

The RC phase ties together everything from regression testing and bug severity triage to version control conventions and stakeholder sign-off. Whether your team follows a formal software development lifecycle model or runs a continuous integration pipeline, some version of this checkpoint belongs in your process.

Projects like the Linux kernel and WordPress prove that structured RC testing catches what beta misses. The label matters less than the discipline behind it.

Get your RC process right, and your stable releases actually earn that name.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web design, focusing on creating user-friendly websites, and innovative UI kits.

Many of his resources are available on various design marketplaces and for free on Codepen.

Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, and Speckyboy, and Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• Ai Pair Programming: The New Way To Write Code - April 12, 2026
• What Is Agentic Coding? The Next AI Dev Workflow - April 10, 2026
• From Setup To Monitoring: Why A DMARC Service Matters - April 10, 2026