Release Candidate Process

Release candidate process manages the final validation stage before design system versions become stable releases. Release candidates (RCs) are feature-complete versions that need only final testing to confirm readiness. The RC process provides a structured approach to this final validation.

What Is Release Candidate Process

A release candidate is a prerelease version considered potentially ready for stable release. The RC stage follows alpha and beta, indicating that all planned features are complete and known issues are resolved. Release candidates undergo final validation to catch any remaining problems before stable release.

The RC process creates a formal checkpoint before committing to a stable version number. If issues are found, additional release candidates are created until one passes all validation criteria. Only then does the version become stable.

How Release Candidate Process Works

RC management involves creating candidates, executing validation, addressing issues, and ultimately promoting to stable. Each step contributes to release confidence.

Creating release candidates happens when beta testing is complete and the version appears ready. The candidate is published with an rc identifier (2.0.0-rc.1). This signals to consumers that the version is in final validation and may soon become stable.

Validation procedures test the release candidate thoroughly. This includes automated testing suites, manual testing of critical paths, consumer validation in realistic scenarios, and documentation review. Validation should be comprehensive since the RC may become the stable release.

Issue resolution handles problems discovered during validation. Critical issues require fixes and a new release candidate (rc.2, rc.3). Minor issues may be documented and deferred. The decision process should be clear about what warrants blocking stable release.

Promotion to stable happens when a release candidate passes all validation. The same code that was rc.1 becomes 2.0.0 stable. This may involve republishing with the stable version number or promoting the rc tag to latest.

Key Considerations

• Define clear validation criteria before creating release candidates
• Limit RC scope to bug fixes only; new features wait for next release
• Set expectations for RC duration to avoid indefinite validation
• Communicate RC status to consumers who may be waiting for stable
• Document what issues would block promotion

Common Questions

How many release candidates should be expected?

The number of release candidates depends on issue discovery and fix success. Ideally, rc.1 passes validation and promotes to stable. In practice, some issues are typically found requiring additional candidates.

Planning for two to three release candidates is reasonable for significant releases. Major versions with substantial changes may need more iterations. Minor releases may pass on the first candidate.

Persistent issues requiring many release candidates indicate problems earlier in the process. If rc.5 or rc.6 is needed, earlier testing stages may need improvement. Each RC should make progress toward stability; stalling suggests underlying issues.

Setting maximum RC counts creates accountability. If a release cannot achieve stability within a defined number of candidates, reassessing the release content may be necessary.

What testing is appropriate during the RC phase?

RC testing should be comprehensive since this is the last chance to catch issues before stable release. However, it differs from earlier testing stages in focus.

Regression testing ensures no functionality broke during beta bug fixes. Full automated test suites should pass. Visual regression tests should show no unexpected changes.

Integration testing validates the release works in realistic consumer scenarios. Representative consumer applications should upgrade successfully. Critical user paths should function correctly.

Documentation validation confirms documentation matches the release. API documentation should reflect actual behavior. Migration guides should work as written. Release notes should accurately describe changes.

Edge case testing explores boundaries that earlier testing might have missed. Error handling, unusual configurations, and stress conditions receive attention. This final exploration often surfaces issues missed in happier path testing.

Summary

Release candidate process provides structured final validation before stable release. Creating candidates, executing thorough validation, resolving issues, and promoting based on clear criteria builds confidence in stable releases. The process should be time-bounded to maintain release momentum.