Uncertain Ordering of Pre‑Release Identifiers in sema Range Satisfaction

Direct Answers

1. No. 1.2.3-alpha.1 does not satisfy >=1.2.3 because every pre‑release has lower precedence than its associated release per SemVer 2.0.0.
2. sema follows the SemVer 2.0.0 precedence algorithm: identifiers are compared left‑to‑right; numeric identifiers are compared numerically, alphanumeric identifiers lexically in ASCII order (case‑sensitive). Example ordering: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-rc.1 < 1.0.0.
3. Pin exact versions for production, test pre‑release upgrades in a staging environment, and treat any range that includes a release lower bound as excluding that release’s pre‑releases. If rollback is required, revert to the last known‑good release tag rather than relying on range semantics.

Confirmed Behavior (sema ≥ 1.0.0)

• Build metadata (after +) is parsed but ignored for precedence.
• A range like >=1.2.3 <2.0.0 matches 1.2.3, 1.2.4-beta.1, 1.9.0, but excludes 1.2.3-alpha.1.
• If the lower bound is itself a pre‑release (e.g., >=1.2.3-alpha.1), then 1.2.3-alpha.1 and higher pre‑releases of 1.2.3 satisfy the range; 1.2.3-alpha.0 does not.
• Wildcard * in a version string throws a synchronous parse error.

Verification Steps

const sema = require('sema');
console.log(sema.satisfies('1.2.3-alpha.1', '>=1.2.3')); // false
console.log(sema.gt('1.0.0-alpha.1', '1.0.0-alpha'));      // true
console.log(require('sema/package.json').version);          // confirm ≥1.0.0

Assumptions & Uncertainty

• Assumes the npm package sema (ehmicky/sema) version ≥ 1.0.0. Older versions or differently named libraries (Go, Rust crates) may deviate.
• Case‑sensitivity follows ASCII: Alpha < alpha.

One Diagnostic Detail Needed

Which exact sema version is installed in your project? Run npm ls sema or check package-lock.json. If it is below 1.0.0, the precedence rules may differ and the above guarantees do not apply.