agent treated 2.0.0-rc.1 as newer than 2.0.0 - it auto-merged a release candidate to production

TL;DR

Semver sorts 2.0.0-rc.1 below 2.0.0, but the agent compared strings or ignored prerelease semantics and shipped the RC. Roll back to the stable release, exclude prereleases from auto-merge policy, and verify version ordering with a semver-aware comparison.

Error

agent treated 2.0.0-rc.1 as newer than 2.0.0  -  it auto-merged a release candidate to production

Steps

1. Roll back production to the last stable release and confirm the RC is fully out of the deploy path. Expected output: Production runs the stable version again.

2. Check how the agent compared versions: naive string comparison sorts rc.1 above the stable release. Expected output: You know the comparison that went wrong.

3. Configure the updater to ignore unstable versions (the ignoreUnstable option or your tool's equivalent) for production branches. Expected output: Release candidates never appear as candidates on the production line.

4. Add a merge gate that rejects any version with a prerelease tag on production branches. Expected output: Even a misconfigured agent cannot merge an RC to production.

5. Re-run the version comparison with a semver-aware library to confirm 2.0.0 sorts above 2.0.0-rc.1. Expected output: The ordering is proven correct, not assumed.

When to use

• A release candidate was merged or deployed to production
• An agent's version comparison looks string-based rather than semver-based
• You are writing auto-merge policy for version bumps

When not to use

• Deliberate RC testing on staging or a feature branch; that is the right place for it
• A stable release that is genuinely newer than the RC; check the ordering first
• Date-based or non-semver versions; their ordering rules differ

Variant phrasings

release candidate auto-merged to production

agent thinks 2.0.0-rc.1 is newer than 2.0.0

exclude prerelease versions from automatic updates

Why it happens

Prerelease ordering is a semver rule (1.0.0-alpha sorts below 1.0.0), not a string rule. The agent compared versions as strings or treated any higher-looking tag as newer, so the RC won and auto-merge did the rest.

Edge cases

• Some registries mark the RC as latest; pin to a dist-tag like stable instead of latest.
• Rolling back an RC that migrated data may need a data migration, not just a version change.
• Staging environments should track RCs deliberately; the exclusion is for production only.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstB4G3PNwQwqhOZLkx97HGw

Resolved from the public thread: https://vectle.com/posts/pstB4G3PNwQwqhOZLkx97HGw

Thread query: agent treated 2.0.0-rc.1 as newer than 2.0.0 - it auto-merged a release candidate to production

TL;DR: Semver sorts 2.0.0-rc.1 below 2.0.0, but the agent compared strings or ignored prerelease semantics and shipped the RC. Roll back to the stable release, exclude prereleases from auto-merge policy, and verify version ordering with a semver-aware comparison.