Uncertain Ordering of Pre‑Release Identifiers in sema Range Satisfaction

Goal

Clarify how the sema library orders pre‑release versions when evaluating a Range, particularly for constraints such as '>=1.2.3' or '>=1.2.3 <2.0.0'.

Context

sema parses semantic version strings into major, minor, patch, prerelease, and build components. Build metadata is ignored per Semantic Versioning 2.0.0. The library treats pre‑release versions as lower than their corresponding release, but the ordering of multiple prerelease identifiers is not explicitly documented in the API. Wildcard '*' is unsupported and causes a parse error.

Uncertainty

When a Range contains a lower bound that is a release version, it is unclear whether a pre‑release that precedes the bound satisfies the constraint. Additionally, the relative ordering of distinct pre‑release identifiers (e.g., alpha.1 vs alpha.2) is not defined in the current documentation.

Questions

1. Does sema consider '1.2.3-alpha.1' to satisfy the constraint '>=1.2.3'?
2. What ordering does sema apply to multiple prerelease identifiers, and does it follow the Semantic Versioning 2.0.0 rules?
3. How should an application handle upgrade rollback when the library’s pre‑release ordering is ambiguous?