semver_constraints

...because I don't like semver::VersionReq.

Usage

Add this to your Cargo.toml:

[dependencies]
# ...snip
# you'll probably want to use versions if you're using version
# constraints
semver = "0.9" 
# the actual constraints library
semver_constraints = "0.1"
# if you want to use serde:
# semver_constraints = { version = "0.1", features = ["serde"] }

See the crate docs for motivation and info on the API.

License

semver_constraints is distributed under the MIT License.

lib.rs:

Defines modified syntax for version constraints.

NIH?

The semver crate's Version is fine. What's not fine is their VersionReq.

The reason we're rolling our own instead of using something like the semver crate is that the requirements for elba conflict with what semver provides. The vector-of-predicate approach which semver provides is too flexible, making it harder to validate versions and perform operations on them (check if one range is a subset of another, etc.). The semver crate also provides some unnecessary operations.

Instead, this module adds features in some places and removes others for flexibility where it matters for elba.

Functionality

Versions in elba take lots of good ideas from Cargo and Pub (Dart) versioning. We follow Cargo's compatibility rules for 0.* and 0.0.* versions to allow for less-stable packages. Additionally, we also follow Cargo's rules when sigils are omitted. However, we purposely elide star notation since it's unnecessary; 0.* == 0, 0.0.* == 0.0. To make parsing easier, < or <= must always precede > or >=, like with Pub. Nonsensical requirements like < 1 > 2 which are valid parses under semver get caught during parsing here. In general, syntax is substantially stricter than in Cargo, and nonsensical constraints are caught immediately when creating the constraint.