Usually no. The Semantic Versioning specification says a pre-release version indicates that it is unstable and may not meet the compatibility requirements of the matching normal version. Keep production update bots on stable releases, and opt in to pre-releases only for a named reason and a limited scope.
What counts as a pre-release
Under the specification, a pre-release is marked by a hyphen and a label after the patch number, such as 2.0.0-alpha or 2.0.0-rc.1. It has lower precedence than the normal version with the same numbers, so 1.0.0-alpha sorts before 1.0.0. A naive tool that compares only the leading numbers can misread the order, so check how yours treats them.
Reasons teams opt in
- You maintain a library and want early warning that a dependency's next major will break you.
- You depend on a fix that exists only in a pre-release, and the maintainers say so.
- You run a dedicated canary branch for early testing.
Reasons to avoid it in production
- Behavior may change between pre-releases with no notice.
- Security fixes are normally released as stable versions, so a pre-release rarely helps your risk.
- Pre-release builds are less widely used, so fewer people have found their problems.
- It is harder to explain in an audit why a production system runs unstable code.
A safe pattern for early testing
- Create a separate branch or repository job for canary testing.
- Allow pre-releases only for the named packages you care about.
- Run the test suite there on a schedule. Report failures to the maintainers if you can.
- Do not merge canary bumps to your main branch. When the stable version ships, let the normal bot proposal take over.
Decision table
| Context | Allow pre-releases? |
|---|---|
| Production application | No |
| Library CI canary job | Yes, narrowly |
| Waiting on a specific fix | Yes, for that package, with a revisit date |
| Internal tools with low impact | Case by case |
Check your configuration
Read your bot's documentation for how it treats pre-release versions by default, and test with one dependency that has a recent release candidate. Do not assume. Behavior varies between tools and between package managers.
Also check that your own version ranges do not quietly accept pre-releases. Many range syntaxes exclude them unless asked, but the exact rule belongs to your package manager, so verify it.
Try it yourself
Click through it at your own pace, or open it full screen. Scan the inventory for version strings that carry a hyphen label, which marks a pre-release in a production dependency list.
Quick check
Does a higher number always mean a newer stable release?
No. 2.0.0-rc.1 is a pre-release of 2.0.0 and sorts below it. It is not a stable release.
Are pre-releases less secure?
Not by definition, but they carry no stability promise and security fixes usually ship in stable versions, so they offer little benefit in production.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
