Release candidate

A release candidate (RC) is a version of software that the team believes is ready for production but needs final validation before release. It's feature-complete, bug-fixed to acceptable levels, and functionally stable. The release candidate phase is the last checkpoint before the software goes live - a period of focused testing to catch any remaining issues while change risk is minimized.

Why it matters

Releasing broken software is expensive. Users lose trust, support teams get overwhelmed, and developers scramble to patch problems under pressure. The release candidate process creates a structured pause between development and deployment, giving teams time to validate quality in conditions that match production.

This pause is particularly valuable for products with infrequent releases. A SaaS product deploying daily can fix problems quickly; a mobile app waiting for app store review or installed software requiring customer updates has a much higher cost per bug. Release candidates help catch issues when fixing them is still easy.

The release candidate process

A typical release candidate workflow looks like this:

Feature freeze. Development on the release is complete. No new features are added; only bug fixes are accepted. This stability allows testing to proceed without chasing a moving target.

RC1 creation. The first release candidate is tagged and built. It's a snapshot of the codebase that could become the final release.

Validation testing. QA runs comprehensive tests: regression testing, integration testing, performance testing, and user acceptance testing. The focus is on finding problems, not proving everything works.

Bug triage. Issues discovered are evaluated. Critical bugs block release and require fixes. Minor issues might be documented as known issues or deferred. Each fix creates risk, so changes are minimized.

RC2, RC3... If significant fixes are made, a new release candidate is created and retested. The cycle repeats until a release candidate passes all checks.

Release approval. When a release candidate meets quality criteria, stakeholders approve it for production deployment.

Release candidate vs. beta

Release candidates and beta releases serve different purposes:

Beta - Feature-complete but expected to have bugs. Shared with external users who understand they're testing unfinished software. Feedback shapes final development.

Release Candidate - Believed to be production-ready. Testing confirms this belief rather than discovering fundamental problems. Users may participate in testing, but they should encounter few issues.

The progression typically flows: Alpha → Beta → Release Candidate → General Availability.

When release candidates make sense

Release candidates add value when:

When to skip release candidates

Modern continuous deployment often eliminates explicit release candidates:

In these environments, the concepts embedded in release candidates (feature freeze, validation, approval) still exist but happen continuously rather than in distinct phases.

Managing release candidate quality

Several practices improve release candidate success:

Define clear criteria. What must be true for a release candidate to pass? Document the checklist: test coverage, performance benchmarks, known issue thresholds, required approvals.

Automate testing. Manual testing is slow and inconsistent. Automated regression, integration, and smoke tests catch problems quickly and reliably.

Limit changes. Every change to a release candidate risks introducing new problems. Reject fixes for minor issues and resist scope creep.

Test in production-like environments. Differences between test and production environments hide problems. Match configurations, data volumes, and traffic patterns as closely as possible.

Communicate status. Keep stakeholders informed about RC progress, blocking issues, and expected timelines. Surprises erode trust.

Common problems

Release candidate phases often struggle with:

Endless RCs. When each release candidate reveals new problems requiring fixes that require new release candidates, the process never converges. This usually indicates inadequate earlier testing.

Pressure to skip validation. Business pressure to ship can compress RC testing, defeating its purpose. Resist shortcuts that trade release quality for speed.

Environment differences. Problems that appear only in production, despite passing RC testing, point to environment gaps that need closing.

Unclear ownership. When nobody clearly owns the release decision, RCs linger waiting for approval. Designate decision-makers upfront.

Customer feedback collected through tools like Klero can inform which areas need the most thorough release candidate testing. When you know which features users rely on most heavily, you can prioritize validation efforts where quality matters most.