.netnugetsemantic-versioning

Is it safe to import nuget package with wildcard instead of patch version in production?


I would like to import some third party nuget package into my project. The latest package version is 2.3.4.5

Would it be safe if I import this packages as 2.3.* so that I benefit from patches to be automatically imported? Having major/minor version explicit should prevent any breaking changes?

What is the best practice in this area? I couldn't find any official recommendation by microsoft of nuget.


Solution

  • Yes, you can either set an explicit version or a limited range "latest" as your referring to. Which is right for your project is very much dependent on your context.

    .NET projects allow for NuGet package version ranges, see here. The default is for a specific version (no automatic update), see Visual Studio below.

    Examples:

    Confidence

    If you trust the author of the package to (really) be using Semmantic Versioning and never alter existing functionality on an update, then go for latest within the Major (2.*).

    IMO - Most project say they are using Semmantic Version as they use a 3 part version number (sigh) but do not actually comply with Semmantic Versioning nor reliable detect breaking changes. So I do not trust them.

    Reproducability

    If you work with a testing team they may require a new change review if a package in the build changes. So then reproducability is important to you. That is, if you rebuild that commit next week it will use exactly the same packages.

    If you come back in a year to rebuild a prior release would you want all of the packages to automatically be the latest? For that matter what is the source of truth for which packages were used?

    Criticality

    How critical is your application? Is the convenience of automatically getting latest work the risk? Or is the risk of functional failure lower than the risk of cyber security issues in packages? Do you do automatic builds?

    Testing

    If you have 100% automated functional tests (not just unit tests) then go for latest as your tests will break the build. No risk!

    So if your team uses continuous deployment with 100% ... go for it.

    (This is actually the only scenario I would consider always using latest automatically)

    Visual Studio (example)

    Microsoft's Visual Studio's default behaviour is to record the version you last imported. If there is an update it will appear in the update list but it will not update until you select a new version (unless you change the version to a range).

    You can also configure the version to never even offer an update like this:

        <PackageReference Include="Semver" Version="[2.3.0]" />
    

    I have this as a later version breaks my application (to be investigated).

    Me

    My practice is always use explicit versions and look if there are updates and security issues regularly. On all of my projects package versions are only ever updated manually.