Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow parsing not-quite-semver versions #25

Closed
wants to merge 2 commits into from
Closed

Allow parsing not-quite-semver versions #25

wants to merge 2 commits into from

Conversation

joshleeb
Copy link

@joshleeb joshleeb commented Oct 27, 2017

Ref. Lenient parsing of not-quite-semver versions dtolnay/semver#142

Change the behaviour for parsing not-quite-semver versions, specifically when there is only a major section, and when there is no patch section. Rather than error out, we check if we are at the end of the string. If so, then we return the version with all the information we know so far and zero out the rest. If we are not at the end of the string then we error out with the same error message.

The version formats this PR addresses are:

  • parse("1") which has major=1; minor=0; patch=0
  • parse("1.2") which has major=1; minor=2; patch=0
  • parse("1.2-beta") which has major=1; minor=2; patch=0; pre=beta
  • parse("1.2+build") which has major=1; minor=2; patch=0; build=build

@joshleeb joshleeb changed the title Allow parsing not-quite-semvar versions Allow parsing not-quite-semver versions Oct 27, 2017
Change the behaviour for parsing not-quite-semver versions, specifically
when there is only a major section, and when there is no patch section.
Rather than error out, we check if we are at the end of the string. If
so, then we return the version with all the information we know so far.
If we are not at the end of the string then we error out with the same
error message.
Add support for parsing versions with the build or the pre section after
minor instead of after the patch. Examples are: `1.2-beta` and
`1.2+build3`.
@steveklabnik
Copy link
Owner

I'm going to have to think about this; my gut says we should follow the spec. I'm open to this PR though.

Let me consider things and get back to you.

@steveklabnik
Copy link
Owner

I think I'd like to keep this crate in accordance with the spec. If I did add it, I would want it to be under a different api, like _lossy or something, and at that point, it could be in a separate crate.

Thank you, but I can't accept this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants