Usually no. The semantic versioning specification marks a pre-release as unstable and says it may not satisfy the compatibility rules of its normal version. Use release candidates in staging, pin them exactly if you must run one, and move to the final version as soon as it ships.
What the spec defines
Semantic Versioning 2.0.0 says a pre-release version may be denoted by a hyphen and dot separated identifiers after the patch number, using only ASCII alphanumerics and hyphens, with numeric identifiers free of leading zeroes. Examples in the spec include 1.0.0-alpha, 1.0.0-alpha.1 and 1.0.0-0.3.7. A pre-release has a lower precedence than its normal version, so 1.0.0-alpha sorts below 1.0.0. The spec also says a pre-release indicates the version is unstable and might not satisfy the intended compatibility requirements of the associated normal version.
Build metadata, written with a plus sign, is ignored when deciding precedence. Two versions that differ only in build metadata have the same precedence.
Why that matters for supply chain risk
| Risk | What happens |
|---|---|
| Unfinished fixes | An rc may include a patch that is not final or tested |
| Different content under a similar name | An rc and the final release are separate artifacts, so scan results do not carry over |
| Fewer eyes | Fewer users and scanners have examined it |
| Attractive for attackers | A package that auto accepts pre-releases may take a malicious one |
Whether your package manager picks up pre-releases by default depends on the tool and the range you wrote, so check its documentation rather than assuming. The safe stance is to make the choice explicit.
A decision guide
- Is there a final version? Use it.
- Do you need a fix that exists only in an rc? Pin that exact version, not a range, and record why.
- Run the rc in a non production environment first, with your tests and a vulnerability scan.
- Add a calendar or ticket reminder to move to the final release.
- Block pre-release identifiers in production builds through a policy, with a documented exception path.
What to record
If an rc does reach production, write down the exact version, the reason, the owner and the date by which it should be replaced. Add the version to your SBOM like any other component. When the final release arrives, compare the two builds rather than assuming they match, because release candidates sometimes receive last minute changes before the final tag.
Also check whether your dependency update tooling proposes pre-releases. If it does, decide whether that is wanted, and configure it deliberately instead of finding out from a pull request.
Publisher side
If you publish release candidates, keep them clearly named, publish them to the same immutable registry rules as finals, and never reuse an rc number after a fix. Move to rc.2. See can you overwrite a published package version.
Safeguard's policy gates can fail a pull request that adds a dependency matching a rule you define, which is one way to keep pre-release versions out of production branches.
Quick check
Does 1.0.0-rc.1 sort before 1.0.0?
Yes. A pre-release has lower precedence than the associated normal version.
Does the plus sign part affect version order?
No. Build metadata is ignored when determining precedence.
Sources
Last reviewed: 19 October 2026.
