Allow multiple pre-release versions of a dependency to co-exist

[Diggsey]

As noted in the semver spec, pre-release versions do not have the same stability requirements as proper releases. Due to this, I believe that cargo should allow selecting multiple pre-release versions of a dependency without causing an error.

Not allowing this causes real problems, as can be seen with the "mime_guess" crate, which accidentally released a 1.0 version before its public dependency (mime) reached 1.0.

The only way for "mime_guess" to follow semver going forward would be to either release a new major version on every patch release of "mime", or (the solution chosen) to switch to only publishing pre-release versions (2.0-alpha1, 2.0-alpha2, etc.) with the hope that "mime" will soon have a 1.0 release and then mime_guess 2.0 proper can be published.

However, this causes headaches for the average user who depends on common crates like "hyper" and "reqwest", because these must now have dependencies on pre-release versions of "mime_guess", which universally conflict with each other.

I think this will be a problem going forward too, as crate versions are forever, so as soon as you publish a 1.0 of a crate, there's no return to allowing multiple versions to be linked.

[dwijnand]

There's a long discussion in #2222 about pre-releases.

[abonander]

cc abonander/mime_guess#26

I will be opening a separate issue, but it would be nice if Cargo warned about publishing a 1.0 release while any dependency is < 1.0. That would have prevented my original mistake of publishing 1.0 while having a < 1.0 public dependency. It shouldn't forbid publishing a 1.0 as < 1.0 private dependencies are fine, but just having a note/confirmation during the publishing process would have been enough.

[alexcrichton]

The Cargo team discussed this change in a team meeting some time ago, and write up our conclusions, and it turns out this is a pretty nuanced topic and change!

[gagbo]

Hello,

I think my current issue is somewhat related.

In my Cargo.toml file, going from

ds3 = { version = "3.1.3", registry = "szl", package = "data-stream" }
ds4 = { version = "4.0.0", registry = "szl", package = "data-stream" }

to

ds3 = { version = "3.2.0-szl", registry = "szl", package = "data-stream" }
ds4 = { version = "4.1.0-szl", registry = "szl", package = "data-stream" }

started to trigger resolution errors like

error: failed to select a version for `data-stream`.
    ... required by package `data-stream v3.2.0-szl (registry `szl`)`
    ... which satisfies dependency `ds3 = "^3.2.0-szl"` of package `gateway-client-js v5.0.0-beta.0 (/path/to/gateway-client-js)`
versions that meet the requirements `>=4.0.0, <5.0.0` are: 4.0.0

all possible versions conflict with previously selected packages.

  previously selected package `data-stream v4.1.0-szl (registry `szl`)`
    ... which satisfies dependency `ds4 = "^4.1.0-szl"` of package `gateway-client-js v5.0.0-beta.0 (/path/to/gateway-client-js)`

failed to select a version for `data-stream` which could resolve this conflict

(Note: I am using moriturus/ktra as the registry, if that is relevant; and even = dependencies fail)

So it definitely looks like to me that prereleases don't mark the major version incompatibility, preventing me from using multiple prerelease from my crate that needs multiple versions. Does that make sense? I don't have a minimum working example now, I don't think I'll be able to make one before next week-end at least.