"pre-release"

[Eh2406]

"pre-release" (in cargo) is part of the semver spec that allows versions like 1.0.0-alpha. I don't know how dart supports this but I believe it does.

This issue is to split off and continue the conversation from pubgrub-rs/pubgrub#39

[Eh2406]

To summarize the comments from pubgrub-rs/pubgrub#39 so far:

mpizenberg: pubgrub-rs/pubgrub#39 (comment)

Pre-release

Pre-releases are versions. So the main question here is if the Version trait can express the kind of behavior that pre-releases are supposed to follow. Under which conditions are pre-releases selectable by Cargo? What kind of constraints enable them being picked in Cargo.toml? is it only for direct dependencies, or can they also being picked for indirect dependencies? How does that play with the patches?

aleksator: pubgrub-rs/pubgrub#39 (comment)

Pre-release

Interestingly handling of pre-release versions still seems to be an open question for cargo: rust-lang/cargo#2222.

Currently they do the following (correct me if I'm wrong):

Under which conditions are pre-releases selectable by Cargo?

Only if specifically requested I believe.

is it only for direct dependencies, or can they also being picked for indirect dependencies?

Only for those packages that requested the prerelease.

Also from pubgrub-rs/pubgrub#49:

seems like something that will prevent usage of things like pre-releases or versions based on dates, floating point numbers or other potentially valid versions otherwise.

For example:
a. Range([1.0.0, Some(1.1.0-beta)]) meaning something like normal versions between 1.0.0 and 1.1.0 and pre-releases of 1.1.0
b. Range([1.1.0-alpha, Some(1.2.0)])meaning something like normal versions between 1.1.0 and 1.2.0 and pre-releases of 1.1.0

So a.union(b) will give Range([1.0.0, Some(1.2.0)]) as 1.1.0-alpha < 1.1.0-beta so we can merge the intervals. Meaning something like normal versions between 1.0.0 and 1.2.0. But v=1.1.0-beta and v=1.1.0-alpha both are accepted by both a and b but not a.union(b), witch seams not great.

Given that kind of tricky corner case I am not seeing a way to support pre-releases without some way to redefine Range.

[Eh2406]

One thing that makes this complicated is that different package managers handle "pre-release" differently.
From the example above I think it will be hard to be sure that a Version trait based solution always gets the correct answer, for any given definition of "correct answer".