Release candidate
A frozen build believed ready to ship, tested as the possible final release and replaced by a new candidate if anything changes.
What it is
A release candidate is an immutable build proposed as the final release and frozen for last-mile validation. A version such as 2.4.0-rc.1 says 'this becomes 2.4.0 if no release-blocking defect appears.' If a fix is needed, the team builds rc.2; it does not quietly replace rc.1.
Reach for one when the same artifact needs coordinated QA, security, compatibility, or customer acceptance before launch. It gives everyone one digest to test instead of a branch that changes underneath them, and SemVer treats rc.1 as a prerelease identifier below the final 2.4.0 version. The Linux kernel runs the same cycle in public, tagging rc1 through rc7 about a week apart before the final release.
Gotcha: rebuilding after approval destroys the evidence. Promote the tested artifact to production without compiling it again, and create a new candidate for every code change. A release candidate means 'possibly final', not 'known bug-free'.
Ask AI for it
Create a release-candidate workflow with GitHub Actions and GitHub Releases. From a selected commit, derive the next SemVer prerelease such as 2.4.0-rc.1, build the artifact once, calculate its SHA-256 checksum, and publish a GitHub prerelease containing the artifact, checksum, commit SHA, and generated notes. Run integration, security, and smoke tests against that exact artifact. If code changes, produce rc.2; if it passes, promote the same artifact digest to the final 2.4.0 release without rebuilding.