Merge semver and semver-parser about semver HOT 9 CLOSED

The serde feature is also already optional in semver.

from semver.

semver-parser has its own dependents too: https://crates.io/crates/semver-parser/reverse_dependencies

One could maybe argue that Version should move into semver-parser, and that semver would re-export it, but basically, any time you want to parse semver versions, but you don't care about things like ranges, only semver-parser is needed.

Basically, I like small, focused crates.

from semver.

This is also discussed in #59

from semver.

I think because semver_parser hasn't received the same doc treatment as semver it feels like an implementation detail rather than a crate in its own right. And an obvious thing to want to do with implementation details is hide them.

So I think if we beef the docs out then semver_parser will stand on its own better.

from semver.

@steveklabnik I'd also like to see this happen. The two crates are currently tightly coupled so that releases must be carefully coordinated (e.g. blocks things like #151 from happening between two releases).

I've spent time working through the existing dependents.

version-sync (renamed duplicate of check-versions)

Uses semver-parser to parse a VersionReq, then implements the compatibility check manually:

https://github.com/mgeisler/version-sync/blob/master/src/lib.rs#L119

Naively it looks like this use-case could be much better served using this crate.
By providing a custom matches implementation it effectively undermines the behavior of this crate.

libvpx-native-sys

Doesn't appear to be using semver-parser any more?

debcargo

Primarily used to parse the VersionReq, then inspect the structure of it.

Used here: https://anonscm.debian.org/git/pkg-rust/debcargo.git/tree/src/debian/dependency.rs

It's worth noting that this uses semver-parser because the structure of VersionReq is private in this crate, but not in semver-parser.
Making the predicates public, or adding accessor methods, would permit them to move.

cargo-tally

Also seems to be a case of providing access to internal structures.

Conclusion

semver-parser could be merged into semver if semver provided access to currently private parts of Version, VersionReq.

from semver.

So I've been needing some of the new semver support (especially #151) for a while, which has blocked me from publishing new versions of my application to crates.io. The slow moving progress on this has caused me to incorporate semver as an internal library (called reproto-semver) which includes all the changes I need.

This effectively unblocks me, and I'm happy to wait until a new version of semver becomes available which does what I need. But I'd like to highlight that I took the approach of merging the parser. This caused a significant reduction in the amount of boilerplate used to communicate between the two crates. The translation was also very straight forward since there's almost a 1:1 mapping between the two.

If you'd like some inspiration of where this project could go if you choose to take this advice of merging the crates, please check out: https://github.com/reproto/reproto/tree/master/lib/semver

from semver.

Sorry about that! I'd been focusing on semver-parser, but then the holidays happened; I hope to have 1.0 of both libs out by the end of the month.

from semver.

Hey no worries! Take the time you need and I'm here to help if you want it :).

from semver.

This has happened in semver 1.0.0.

from semver.