Support package restore to work with "highest" while following constraints

[giggio]

This is a feature request.

We need to be able to tell Nuget (and VS) to restore the highest available version from a package. Right now it always resolves to lowest.

For example, if my app dependes on "[1,2)", this means I depend on at least version 1, and I accept anything up to version 2. But if 1.0.0 and 1.1.0 exist, Nuget will always get 1.0.0.
There is no config at this moment that allows Nuget to get the highest available version that works with a version spec. A higher version will only be selected if there is another package restricting the dependence to a higher range.

This is really important for package authors for fixing security issues, releasing minors, etc.

Node is a good example on how to work this.
Node allows patch updates with ~, like ~1.0.0 (anything from 1.0.0 to 1.1.0 - not included) and minor updates with ^, like ^1.0.0 (anything from 1.0.0 to 2.0.0 - not included).
Node also allow for wildcards with the x, like 1.x (anything greater or equal to 1.0 and lower than 2).

Brought over from aspnet/dnx#2657

[bbowman]

I agree. * is sort of close but we do a *-* or similar version specifier. To work around this in the authoring case, I have made a .targets to take locally built packages first. @emgarten, @rrelyea and @yishaigalatzer were trying to get the - feature in for 4.0 but it didn't make it. They may know more on the current state.

[citizenmatt]

If this is about PackageReference always choosing lowest version, then I'm adding my +1.

My situation is that I want to have a floating version to take a dependency on a pre-release, and always pick up the latest pre-release when I restore. Using something like 108-* will match pre-releases, but always picks the oldest/lowest version, ignoring the newer versions. There doesn't seem to be any way to override this behaviour.

[emgarten]

Duplicate of #5553
Duplicate of #1192