Best practice regarding PackageReference version when publishing Nuget packages?

user_13186285 0
Viewed 675

What is the best practice when specifying the PackageReference when publishing Nuget packages?

According to https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files, specifying the version number is equivalent to >= that version.

For example the following would reference version 11.0.1 or later of Newtonsoft.Json and 106.9.0 or later of RestSharp.

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="11.0.1" />
    <PackageReference Include="RestSharp" Version="106.9.0" />
  </ItemGroup>

If another developer wants to use my Nuget package in his project, that same developper may also need those same packages within his project and he may not be able to nor want to work with the same versions that I have been using. As such, what is the best practice? Should I always specify the lowest compatible version when I publish or do I just update my packages as I see fit for my project and not worry about the version numbers that get published?

nuget .net c#
2 Answers

Speaking from a consumer standpoint I'd say, yes, you should specify the lowest compatible version. That way, as you mention, you are not enforcing consumers of your package to have to upgrade e.g. their Newtonsoft.Json dependency if they happen to have a direct dependency to that package's version 11.0.0. If for some reason you won't allow version 11.0.0 to be used, then of course you should specify 11.0.1.

If, for example, you know Newtonsoft.Json version 11.0.1 has a critical security vulnerability, you may want to enforce a new version if it's been patched. But in general I think, as a package provider, you'd be interested in making your package as compatible as possible for the consumers' sake. Although, that doesn't mean you shouldn't keep the package up-to-date with its dependencies.

user_30342730

There is always a trade-off. Your library package reference version could become outdated for things outside your control. For example, if you have no new feature to release for your library but one of the dependent libraries is been updated, you may not want to update your Nuget. That said if there are some critical security updates that you would need to update your library.

Slightly, unrelated but one of the old recommendations from .NET Standard may come in handy for you to make your decision.

When choosing a .NET Standard version to target, consider this trade-off:

  • The higher the version, the more APIs are available to your library's code.
  • The lower the version, the more apps and libraries can use your library.

Personally, when working with Nuget packages, I try to use the latest of the dependent packages to ensure I can get the latest features without worrying about the security vulnerability.

user_9211270
Related