Add nuget level option for "resolve highest"

[SimonCropp]

I want a way for a nuget package to say it wants the "highest version within the dependency range"

There are many packages where this makes the most sense. for example bootstrap packages that help people get started https://www.nuget.org/packages/NServiceBus.Bootstrap.WindowsService

It really should be up the the package author how the dependency is resolved.

[emgarten]

Packages should depend on a minimum version which is known to work. Assuming a future version will always work often leads to problems over time when the dependency is owned by a different author and it goes through breaking changes.

Project.json allows floating versions to solve the problem of always needing the highest, but only the user can set this. If each package could specify it's own floating behavior for a dependency it would quickly get out of hand and lead to behavior conflicts when packages had different settings for the same package.

[SimonCropp]

behavior for a dependency it would quickly get out of hand and lead to behavior conflicts when packages had different settings for the same package

How would this get our of hand? isnt this very similar to a user setting <add key="DependencyVersion" value="Highest" />

Either way resolving to "the highest in a dependency range" is the most likely what people want.

For example I manage several fody nugets https://www.nuget.org/profiles/simoncropp. i regularly get people saying

I installed the fody addin X and it incorrectly installed an old version of fody that has bugs, please fix your nugets

Each time i respond with

there is nothing i can do, dependency resolution is broken in nuget, every time you install any nuget you need to immediate do an update to check if you have installed an older, and most likely buggy, dependency.

So I would much prefer that the default resolution was "HighestMinor". That is the most likely to be correct from a consumers perspective. Failing that i would like to control dependency resolution at the nuspec level.

[SimonCropp]

also

Packages should depend on a minimum version which is known to work

I think you are conflating "what a package says is its minimum" and "what is a sensible approach when first installing dependencies"

Assume a package says it is compatible with version 1.0 from 2 years ago and there is a 1.0.15 from 2 weeks ago. So there are at least 15 bug fixes in that dependencies. Why would you resolve the clearly out of date 1.0 version. Also assuming that package follows semver then the highest 1.x should be resolved.

[emgarten]

I see that many of the Fody packages do not specify a version range for the Fody dependency. This is going to cause users to get the oldest available version. You can fix this by setting the minimum version to the current release of Fody when releasing new packages.

Users typically want their packages to "just work" and for most packages happens when using the packages specified in the minimum versions because that is what the package author created and tested their package with.

NuGet encourages packages to follow the semver rules, but this isn't always the case, and even when a package does use semver a "bug fix" from one author can end up changing behaviors that break packages from another author depending on them. In your scenario if the 1.0.15 package broke the parent package the other author would need to go in and release another package with a maximum version of 1.0.14 just to keep new installs working.

Users can set the flag you mentioned and it is also available in a UI drop down to make it easy for users who want to install the latest dependencies to get just that. For your packages it makes sense to always take the highest version since you also own the dependency package and are careful about not breaking things, but for the majority of packages this isn't the case.

[SimonCropp]

This is going to cause users to get the oldest available version

No the nuget practice of resolving oldest causes this

You can fix this by setting the minimum version to the current release of Fody when releasing new packages

Yes and this results in the un-maintainable scenario of deploying a nuget every time its dependencis deploy just to update the nuget range

Users typically want their packages to "just work" and for most packages happens when using the packages specified in the minimum versions because that is what the package author created and tested their package with.

This is a assumption that is plainly false since people will never get bug fixes for dependencies. It is basically a stance that ignore semver

NuGet encourages packages to follow the semver rules, but this isn't always the case, and even when a package does use semver a "bug fix" from one author can end up changing behaviors that break packages from another author depending on them

Yes this is true but this is a problem for people managing packages to handle, not nuget. For example http://docs.particular.net/nservicebus/rabbitmq/rabbitmqclient-nuget
By resolving oldest you are effectively just hiding the issue until they do an update. The breaking change will still impact the user, just at a later point.the consumer is no better of with resolving oldest.

Users can set the flag you mentioned and it is also available in a UI drop down to make it easy for users who want to install the latest dependencies to get just that

Yes but this is a setting they need to switch every single time they install a package. It is also a setting they need to remember when using the command line.

For your packages it makes sense to always take the highest version since you also own the dependency package and are careful about not breaking things, but for the majority of packages this isn't the case.

What are you basing this on? For all the packages I consume (with the exception of rabbit) i want the newest dependencies.

[RichiCoder1]

I'm with @SimonCropp on this. I just recently went through the unnecessarily gargantuan task of setting up a new framework with in a few of our products at my job and ran it many cases were because of this "oldest" default, I was installing ancient versions of nuget packages, or, in cases were I might have already installed a dependency, multiple different versions of the same package. I ended up doing a mass update run, and was forced to reset the "Highest Minor" switch every time I went into a new project.

NuGet encourages packages to follow the semver rules, but this isn't always the case, and even when a package does use semver a "bug fix" from one author can end up changing behaviors that break packages from another author depending on them

I'd point out that this might make a good case for NuGet users not to default to "Highest Minor", but package owners are probably much more sure about how their dependent packages are versioned.

For your packages it makes sense to always take the highest version since you also own the dependency package and are careful about not breaking things, but for the majority of packages this isn't the case.

What are you basing this on? For all the packages I consume (with the exception of rabbit) i want the newest dependencies.

Agreed. With the exception of some very edge cases (JQuery), I usually want the newest version of minor always, and the newest verions of major often.

NuGet encourages packages to follow the semver rules, but this isn't always the case, and even when a package does use semver a "bug fix" from one author can end up changing behaviors that break packages from another author depending on them. In your scenario if the 1.0.15 package broke the parent package the other author would need to go in and release another package with a maximum version of 1.0.14 just to keep new installs working.

I would argue then that this is the Author's responsibility. I would also argue for allowing a user to override a packages dependency resolution hint to make it more conservative if they so desire. I'd argue making it more liberal (highest minor/patch) is more often more desirable than more conservative.

[emgarten]

@RichiCoder1 would setting the default dependency behavior in your nuget.config have helped? Or is the global setting too broad for the packages you were installing?
https://docs.nuget.org/release-notes/nuget-2.8#dependencyversion-attribute

in cases were I might have already installed a dependency

If a new package specified that an already installed package should be the highest version would you expect it to force an update? What if the user installed that specific version manually?

[SimonCropp]

If that setting worked it would mitigate it. Unfortunately i have never gotten that to work
My config C:\Users\simon\AppData\Roaming\NuGet\NuGet.Config

has had this for ages

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="DependencyVersion" value="Highest" />
  </config>

and from my nuget "dialog"

so clearly this is not true

This value will also be respected by the NuGet Package Manager Dialog for any install package operations.

But this only fixes the problem for me, not for the many people who use the ~80 packages i manage. as i said I want to reduce the occurrence of "your nuget is broken since it resolved a version with bugs"

[RichiCoder1]

would setting the default dependency behavior in your nuget.config have helped? Or is the global setting too broad for the packages you were installing?
https://docs.nuget.org/release-notes/nuget-2.8#dependencyversion-attribute

It would have been a little to broad, but I'll admit I didn't even know that config setting existed. That's a little off the beaten path and out of the way of the happy path.

in cases were I might have already installed a dependency

If a new package specified that an already installed package should be the highest version would you expect it to force an update? What if the user installed that specific version manually?

Hmm. That's actually a good question. If they explicitly said that they want the highest when installing a depdendent package, I would, but if it was unspecified I'd just keep the installed version as long as it fit the dependency version check. Though that also brings the argument of being able to "pin" package versions so a package has to be explicitly and manually updated.

[xavierdecoster]

Defaulting to oldest known compatible is the safest resolution a package manager can do not knowing for sure that package authors apply SemVer (which isn't exact science either, mistakes happen, assumptions are...). When such mistakes happen, all packages depending on it are affected when choosing highest version resolution, and people will blame the tool for not protecting against it (I believe this happened in the past?). Consumers have the experience of dealing with specific packages and have the option to choose differently, typically before the install operation starts. Providing the author with the option to define resolution behavior is a dangerous thing to do if you depend on other packages you don't control, and ultimately will break consumers if one of those gets updated to a breaking change without reason (you might not have changed the minimum version of your dependency, but the resolution behavior you defined would overrule that). I'm sure you'd want NuGet to respect that constraint instead?

I was installing ... in cases were I might have already installed a dependency, multiple different versions of the same package.

This is something I believe NuGet can be smarter about. See this issue I logged when experiencing the same unconsolidated install when newer dependencies were already installed in the solution: #835.

[RichiCoder1]

Providing the author with the option to define resolution behavior is a dangerous thing to do if you depend on other packages you don't control...[snip]

Which is why I would argue for allowing the author to hint a better default if they're certain that the 99% case is that it'll be better for the user, but still allow the user to override that hint should they wish.

I was installing ... in cases were I might have already installed a dependency, multiple different versions of the same package.

This is something I believe NuGet can be smarter about. See this issue I logged when experiencing the same unconsolidated install when newer dependencies were already installed in the solution: #835.

That would be awesome, and would resolve my specific issue. Managing packages across projects, especially when updating them or installing new packages, feels very messy at the moment.

[emgarten]

@SimonCropp good catch, that looks like a UI bug to me. Please copy that into a new issue so it can get fixed.

Yes and this results in the un-maintainable scenario of deploying a nuget every time its dependencis deploy just to update the nuget range

This would help new installs, but at some point the user needs to update their Fody package themselves. For example if they install BasicFodyAddin.Fody today, get the current highest version of Fody, but tomorrow Fody is updated they are once again missing out on bug fixes.

project.json solves this by allowing users to float to the highest version of a package on every restore/build.

[SimonCropp]

project.json solves this by allowing users to float to the highest version of a package on every restore/build.

I would also consider that a bug if enabled by default. It means OOTB i can get different build behavior with no code changes.

[DanTup]

This always confuses me.. People shouldn't have to narrow the range of versions they support just to avoid people getting buggy versions.

If a jQuery plugin supports "every version of jQuery ever", it would never makes sense to install and old buggy version.

It seems valid for a package to want to express a preference that is narrower than the supported version.

Dragging the minimum supported version forwards will only make resolution harder. The smaller the ranges of supported versions, the more likely you'll end up with an unresolvable set of dependencies.

[SimonCropp]

If a new package specified that an already installed package should be the highest version would you expect it to force an update? What if the user installed that specific version manually?

I would be happy with the setting being a "soft recommendation"