What is a Release Candidate (RC)?

A Release Candidate (RC) is a version of software that has passed all planned testing and is considered potentially ready for production release. It represents the final stage before the official, stable version is published. If no critical bugs are found during the RC phase, the RC becomes the official release without further code changes.

According to the IEEE Standard 1012-2016 on software verification and validation, the release candidate phase serves as the "final quality gate" where software must demonstrate it meets all specified requirements and is free of known critical defects. The DORA (DevOps Research and Assessment) team at Google Cloud found that organizations with well-defined release processes, including structured RC phases, experience 3x fewer change failure rates than those without (Forsgren, Humble & Kim, Accelerate, IT Revolution Press, 2018).

As Martin Fowler, Chief Scientist at ThoughtWorks, notes: "The whole point of continuous delivery is to make releases boring. A release candidate should be just another step in the pipeline, not a stressful event." (martinfowler.com)

Software progresses through several maturity stages before reaching users. Understanding these stages is essential for effective release management.

Pre-Alpha

The earliest phase of development where core features are being built. The software is incomplete, unstable, and not suitable for any external testing. This phase includes:

• Architecture prototyping
• Core feature implementation
• Internal developer testing

Alpha

The alpha version is the first feature-complete (or near-complete) build of the software. Key characteristics:

• Audience: Internal team members, QA engineers
• Stability: Unstable; crashes and major bugs are expected
• Purpose: Validate that core features work at a basic level
• Duration: Varies widely; weeks to months depending on project size

Alpha testing typically uncovers fundamental design issues and major functional defects. According to Capers Jones (Applied Software Measurement, McGraw-Hill, 2008), approximately 85% of severe defects are found during the alpha phase in well-managed projects.

Beta

The beta version is more stable than alpha and is released to a wider audience for real-world testing. There are two types:

Closed Beta (Private Beta):

• Limited to invited users or specific groups
• Participants sign NDAs or agree to testing terms
• Feedback is structured and tracked

Open Beta (Public Beta):

• Available to anyone who wants to participate
• Larger volume of feedback, more diverse testing conditions
• Often used as a marketing strategy to build anticipation

Notable beta programs include:

• Google famously kept Gmail in beta for 5 years (2004-2009), processing feedback from millions of users
• Microsoft runs the Windows Insider Program with over 10 million participants who test pre-release builds
• Apple offers public betas of iOS and macOS through the Apple Beta Software Program

Statistically, beta testing catches 60-70% of user-facing defects that survive alpha testing (Jones, The Economics of Software Quality, 2011).

Release Candidate (RC)

The RC phase comes after beta and represents the "we think this is ready" stage:

• Audience: Internal QA, select external testers, staging environments
• Stability: Should be production-ready; only critical bugs warrant fixes
• Purpose: Final validation before committing to the official release
• Duration: Typically 1-4 weeks, depending on risk tolerance

RC numbering convention:

• v3.0.0-rc.1 — First release candidate
• v3.0.0-rc.2 — Second candidate (if rc.1 had critical issues)
• v3.0.0 — Final release (if rc.2 is approved)

Release to Manufacturing / General Availability

• RTM (Release to Manufacturing): Traditional term from when software was distributed on physical media. The code is "done" and ready for duplication.
• GA (General Availability): The modern equivalent, indicating the software is available to all customers through digital distribution.
• RTW (Release to Web): Specific to web-based distribution.

Post-Release

After GA, the release lifecycle continues with:

• Service Packs / Point Releases: Cumulative updates (e.g., v3.0.1, v3.0.2)
• Hotfixes: Emergency patches for critical production issues
• End of Life (EOL): The version is no longer supported or updated

Pre-Alpha → Alpha → Beta → RC.1 → [RC.2...] → GA/RTM ↓ ↓ ↓ ↓ ↓ Internal Internal Public Final QA Production Dev Only QA Testing Validation Release

During the Release Candidate phase, testing focuses on validation rather than discovery. The goal is to confirm the software is ready, not to find new issues.

Types of RC Testing

Go/No-Go Decision

The RC phase culminates in a go/no-go decision. According to ITIL 4 (IT Infrastructure Library), this decision should be made by a Change Advisory Board (CAB) or release authority based on:

1. Test pass rate: Are all critical and high-priority test cases passing?
2. Open defects: Are there any unresolved critical or blocker bugs?
3. Performance benchmarks: Does the RC meet SLAs for response time, throughput, etc.?
4. Security scan results: Are all critical vulnerabilities addressed?
5. Stakeholder sign-off: Has the Product Owner approved the functionality?
6. Rollback plan: Is there a tested procedure to revert if issues arise?

The Semantic Versioning specification (semver.org) defines how release candidates fit into the versioning scheme:

MAJOR.MINOR.PATCH-prerelease+buildmetadata

Pre-release versions:

• 1.0.0-alpha.1 — Alpha release
• 1.0.0-beta.1 — Beta release
• 1.0.0-rc.1 — Release candidate

Precedence rules (from lowest to highest):

1.0.0-alpha.1 < 1.0.0-alpha.2 < 1.0.0-beta.1 < 1.0.0-rc.1 < 1.0.0-rc.2 < 1.0.0

This means package managers (npm, pip, Maven) correctly order pre-release versions, allowing users to opt into or avoid RC builds.

Linux Kernel

The Linux kernel follows a well-defined RC cycle managed by Linus Torvalds:

1. Merge window (2 weeks): New features are accepted
2. RC cycle (6-8 weeks): rc1 through rc7 (or more)
3. Final release: When Torvalds deems the code stable

Each kernel RC is available at kernel.org and is tested by thousands of developers worldwide. According to Linux Foundation data, the kernel 6.x series averaged 7 release candidates per version.

Chrome/Chromium

Google Chrome uses a 4-channel release process:

• Canary: Daily builds, highly unstable
• Dev: Weekly updates, somewhat stable
• Beta: Updated every 2 weeks, release candidate equivalent
• Stable: The production release, updated every 4 weeks

Enterprise Software (SAP, Oracle, Microsoft)

Enterprise vendors often have extended RC phases due to the impact of failures:

• Extended testing periods: 4-12 weeks of RC testing
• Customer validation programs: Key customers test RCs in their environments
• Staged rollouts: GA released to regions/customers in phases

1. Freeze the code

Once an RC is created, apply a code freeze. Only critical bug fixes should be allowed. Every non-critical change increases risk and invalidates prior testing.

2. Use the same build artifacts

The RC binary/container should be the exact same artifact that becomes the GA release. Do not rebuild the code between RC approval and GA. As Jez Humble and David Farley state in Continuous Delivery (Addison-Wesley, 2010): "You should only ever build your binaries once. Any time you build from source, you risk introducing differences."

3. Test in production-like environments

RC testing should occur in environments that mirror production as closely as possible:

• Same infrastructure (or equivalent)
• Realistic data volumes
• Same network configuration
• Same security controls

4. Define clear exit criteria

Before creating the RC, define what "ready for release" means:

• Zero critical/blocker bugs
• Performance within defined SLAs
• All security scans clean
• Documentation updated
• Release notes written

5. Automate the RC pipeline

Modern CI/CD pipelines can automate RC creation:

# Example GitHub Actions workflow for RC name: Create Release Candidate on: workflow_dispatch: inputs: version: description: 'RC version (e.g., 2.1.0-rc.1)' required: true jobs: create-rc: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run full test suite run: npm test - name: Run security scan run: npm audit --production - name: Build release artifact run: npm run build - name: Create GitHub Release uses: softprops/action-gh-release@v1 with: tag_name: v${{ inputs.version }} prerelease: true files: dist/*

6. Communicate clearly

Stakeholders need to know:

• What is included in the RC
• What has changed since the last RC (if applicable)
• Known issues and workarounds
• Timeline for go/no-go decision
• Rollback procedure if issues are found post-release

"Just one more fix" syndrome

Adding non-critical fixes to an RC is one of the most common mistakes. Each change requires re-testing and resets the confidence clock. As the saying goes: "A release candidate with changes is not a release candidate."

Insufficient RC testing time

Rushing through the RC phase to meet deadlines defeats its purpose. A 2019 study by the Consortium for Information & Software Quality (CISQ) estimated that poor software quality costs the U.S. economy $2.08 trillion annually, with a significant portion attributable to inadequate pre-release testing.

No rollback plan

Releasing without a tested rollback procedure is like flying without a parachute. The DORA research shows that elite teams can recover from failures in under 1 hour because they invest in rollback automation.

How many Release Candidates should we expect?

Ideally, 1-2 RCs per release. If you consistently need 3+ RCs, it suggests issues upstream in the development or testing process. The Linux kernel averages 7 RCs, but that reflects the scale and complexity of an OS kernel with millions of lines of code.

What is the difference between RC and Beta?

A beta is for discovering new issues through broader testing — bugs are expected. An RC is for confirming that all known issues are resolved — it should be production-ready. Beta testing is exploratory; RC testing is confirmatory.

Can we skip the RC phase?

In Continuous Delivery environments with mature CI/CD pipelines, every successful build is effectively a release candidate. The formal RC phase may be replaced by automated quality gates. However, for major releases, new products, or regulated industries, an explicit RC phase provides valuable risk mitigation.

What happens if a critical bug is found in an RC?

1. Fix the bug in the codebase
2. Create a new RC (increment the RC number: rc.1 → rc.2)
3. Re-run the full RC test suite on the new candidate
4. Repeat the go/no-go evaluation
5. Never patch an existing RC — always create a new one

How does Release Candidate relate to DevOps?

In DevOps culture, the RC concept evolves from a discrete phase to a continuous quality gate. With practices like trunk-based development, feature flags, and canary releases, the traditional RC phase is replaced by automated pipelines that validate every commit. The DORA metrics (deployment frequency, lead time, change failure rate, mean time to recovery) provide quantitative measures of how effectively a team manages the journey from code change to production release.