Skip to content

Tweak handling of pre-release versions and wildcard ranges #188

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

Closed
wants to merge 2 commits into from

Conversation

mbrubeck
Copy link

No description provided.

Fall back to the highest version only when normal semver matching fails.
This will allow wildcard ranges like `1.5.*` to match pre-release
versions if no other matching versions are found.
@mbrubeck
Copy link
Author

cc dtolnay/semver#98

@onur
Copy link
Member

onur commented Mar 21, 2018

I don't know what is wrong with my current implementation. * means any and it should match any version. It doesn't matter if it has pre-release string or not. I also stated this in commit message when I added that code: onur@21f5caf It also fixed this issue: https://github.com/onur/docs.rs/issues/80

@steveklabnik is following javascript imlementation of semver for some reason, and even in the previous versions of javascript's semver, * matches any latest version (with or without pre-release string).

According to @isaacs in dtolnay/semver#128, * is a range and a version with a pre-release string cannot match in a range. I personally don't care if it's a range or not. * should mean any and it should match any version. And I don't know how a version like this: 1.0.0-rc1 cannot be a real release and why * shouldn't match this version.

Maybe we should stop following javascript implementation of semver and make Rust's semver more sane @Xion.

@isaacs
Copy link

isaacs commented Mar 21, 2018

In node-semver and the semver crate, * means "any non-prerelease version".

I don't know where you got the idea that * must mean "any". Even in the context of file system globs, * typically won't match dot files.

But it's your repo so do whatever you want. If you don't want my opinion, don't tag me into conversations.

@onur
Copy link
Member

onur commented Mar 21, 2018

So, this is what you get when you talk with javascript people. I know * doesn't mean any, that's the whole issue here. It must act like any that is what I am trying to say. I also don't think it's relevant to compare system globs to version strings.

@steveklabnik
Copy link
Member

So, this is what you get when you talk with javascript people.

Please don't do this. If you're going to treat people like this, then I don't want to be tagged into convos either.

@onur
Copy link
Member

onur commented Mar 21, 2018

OK fine, sorry everyone I have strong opinions about this. I believe node's semver is doing wrong by excluding versions with pre-release strings from ranges and I also believe Steve is encouraging this nonsense usage by following node's semver.

Also docs.rs is not encouraging anyone to use * in any way. I don't know why this is even a issue. Do people actually look documentation URL and pick * for their dependency version? Using * in URL is actually causing some browser cache issue. I think I will just redirect to actual version when * used in URL. And if anybody is confused about * usage in docs.rs use crates.io when picking up a dependency. Using * for any is making my life much easier in docs.rs and I'd like to keep it as it is.

@onur onur closed this Mar 21, 2018
@Xion
Copy link

Xion commented Mar 22, 2018

The issue is not just about what * means, but what docs.rs considers the newest version. Currently, it urges users that e.g. browse the 1.x docs of the futures crate to view the alpha 2.0 instead by adding a prominent "Go to latest version" link in the header. While hosting docs for pre-release crates is certainly useful for people who want to try them, I don't think we want to funnel casual bystanders into unofficial releases like 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.

5 participants