Support version numbers lacking minor or patch parts

[jszwedko]

I'm interacting with an external system that returns version numbers lacking a patch part (like 2.1). I think it'd be fair to parse this as 2.1.0. Currently it rejects parsing with "expected more input". I'd similarly think that 2 could be parsed as 2.0.0.

I'm happy to take a stab at this in a PR, but wanted to get confirmation first given there are tests that are explicitly rejecting versions lacking minor or patch versions:

https://github.com/steveklabnik/semver/blob/051c39c50d565c597be65c4496597c7d16a514d9/src/version.rs#L399-L401

[porkbrain]

This would be great. Could be hidden behind a feature not-strict or something like that? As an example from the wild: I use semver to serialize JSON from WP APIs. They just released a version 5.6, which means I cannot use this crate any more.

EDIT: There's the lenient_semver crate as an alternative to people who need to support semantic versions that don't adhere to the spec. Unfortunately the crates differ in APIs in at least two important ways:

• lenient_semver doesn't implement FromStr for its lenient_semver::Version struct
• lenient_semver:Version requires a lifetime parameter

[porkbrain]

I forked this crate with just one change - support for versions 1 and 1.2, which default to 1.0.0 and 1.2.0 respectively. You can replace all semver:: with forgiving_semver:: and it should work out of the box. I am going to publish all new semver releases starting from version 0.11.0 until this crate supports a feature flag for forgiving parsing.

[sunshowers]

A feature flag is not the right way to do it, since features are unified across a build graph and other dependencies might expect strict version parsing.

(I don't think semver is the right place for this at all, to be honest. semver very specifically defines versions as having 3 components. A different crate like lenient_semver is the right approach.)

[dtolnay]

I agree with #219 (comment) — I would prefer that these not parse.

I've updated the readme to indicate that if you are dealing with version numbers that are different from how Cargo interprets the SemVer spec, then this is not the crate you should be using.

[theoparis]

A feature flag is not the right way to do it, since features are unified across a build graph and other dependencies might expect strict version parsing.

(I don't think semver is the right place for this at all, to be honest. semver very specifically defines versions as having 3 components. A different crate like lenient_semver is the right approach.)

This is unfortunate, as I am writing a package manager for my linux distribution and it seems like the alternative you mentioned is not maintained 😕

It seems like forgiving-semver isn't maintained either....