guides

A release candidate is not a beta with a more serious name. It is a specific claim: this is the build we intend to ship, and unless somebody finds a blocking problem, it becomes the final release without further changes. On some projects the RC and the release are the same bytes with a different label.

What the label actually claims

That claim is what makes the label useful, and it is also what makes it easy to misread. An RC does not mean the software is bug-free. It means the team has stopped adding things and no longer knows of a reason not to ship.

Two consequences follow. The first is that an RC is the last moment when reporting a problem still changes the outcome, which is exactly why vendors publish them. The second is that a rising RC number is a signal in itself: if you see rc.4, three previous candidates were rejected, and the release is less settled than the word suggests.

It is also worth knowing that the term is a convention rather than a standard. Nothing enforces what a vendor means by it. Some ship an RC that becomes generally available unchanged; others keep patching after the label appears. The word alone guarantees nothing, and the project's own release notes are the only thing that settles it.

Alpha, beta, rc: a ladder of completeness

The ladder below it is a ladder of completeness, not of quality, and the distinction is the part people get wrong.

• alpha - incomplete, interfaces may still change, breakage expected
• beta - feature-complete, bugs still being found
• rc - nothing known is blocking, ships as-is if nothing new appears

An **alpha** is incomplete. Features are missing, interfaces will still change, and breakage is expected rather than reported. A **beta** is feature-complete: everything that will be in the release is present, and what remains is finding out what is wrong with it. A **release candidate** adds one more claim on top, that nothing known is blocking. The three stages differ in what has been finished, not in how carefully it was written:

How SemVer orders a prerelease

Semantic versioning encodes exactly this ordering, and reading it literally answers most of the questions. Prerelease identifiers hang off the version with a hyphen, and a prerelease always sorts **before** the release it belongs to, so 1.2.0-rc.1 comes before 1.2.0.

Within the prerelease part, dot-separated identifiers are compared one by one. Numeric identifiers are compared numerically and rank lower than alphanumeric ones, which is why 1.2.0-alpha.1 precedes 1.2.0-alpha.beta, and why rc.2 correctly follows rc.10 only if you remember they are numbers. Our note on [semantic versioning](/articles/what-is-semantic-versioning) covers the rest of the grammar.

Your package manager will not take one by accident

Here is the practical part that surprises people, and it is a safety feature rather than a bug. A normal version range does **not** match a prerelease. If your manifest asks for ^1.2.0, it will not pick up 1.3.0-rc.1, even though the number is higher. You have to name the prerelease explicitly, or use a range that already contains one at the same major.minor.patch.

That rule is why an RC never lands in your build by accident, and it is also why testing one is a deliberate act: you pin it, on purpose, in an environment where you can afford the answer.

What to do with one

Which leads to the honest guidance. Run release candidates in CI and on a staging machine, not in production, unless the RC contains a fix you specifically need and you have accepted what that costs. If you do run one, report what you find, because that is the entire purpose of the exercise and the window closes when the release ships. And read the [changelog](/articles/what-is-a-changelog) between the last RC and the final build: if it is empty, the candidate you tested is the release you will get, which is the best news this process can give you. For long-lived systems where you would rather not be near the edge at all, the [LTS route](/articles/what-is-an-lts-version) exists precisely to avoid this decision.