When updating to a new major version of .NET (in this case from .NET 5 to .NET 6) without needing to make any change other than selecting the new target framework in Visual Studio, does this warrant a new major or minor version or does bumping the patch version suffice, when adhering to SemVer-principles?

When I updated from .NET Framework 4.8 to .NET 5, that was a reason to bump the major number imo, as there were a lot of changes made internally, but for the above case I'm not sure.

My app is a local executable for end users, I have no API people will have to rely on. I know it's not that important under those circumstances, but I'm still new to developing and want to learn it the "right" way from the start.

  • 4
    Who is consuming that semantic version?
    – jonrsharpe
    Jun 17, 2022 at 10:10
  • My app is for end users, I have no "real" API people will have to rely on if that's what you mean. I know it's not that important under those circumstances, but I'm new to developing and want to learn it the "right" way from the start : )
    – Rsge
    Jun 17, 2022 at 10:15
  • The point of semver is that consumers of your API can understand when their use of it may break and they'll need to make changes. If your consumers are end users, semver would likely apply only to the UI, not the technical implementation.
    – jonrsharpe
    Jun 17, 2022 at 10:18
  • Ok, so in my case it would be minor or patch level, as the user wouldn't see anything regarding framework. But suppose I had an API, but wouldn't have to change anything about it when bumping the framework, would that still hold true?
    – Rsge
    Jun 17, 2022 at 10:20
  • 3
    A technology change from .Net Fw 4.8 to 5.0 will definitely cause a breaking change for libraries based on that technology.
    – Doc Brown
    Jun 17, 2022 at 11:19

2 Answers 2


Unless the update to the .NET Framework would affect consumers of the package or its API, I would increment the patch version number when updating dependencies.

Both the major and the minor version numbers are incremented with functional changes, with the major indicating backwards-incompatible changes and the minor indicating backwards-compatible changes. The patch version is for bug fixes, and I would argue other technical enhancements or enablements, that are backwards compatible.

The only case for updating something other than the patch version number would be if you introduced other functional changes at the same time as the dependency updates or if the dependency update could cause a breaking change for some consumers.

Partly, this depends on how your application is distributed. For example, if you are versioning an API that is consumed over HTTP, your dependencies have far less of an impact on consumers than if you are creating a library that gets included into a larger application, where upgrading technical dependencies could require consumers to install additional dependencies or invalidate existing installations upon update.

  • Wouldn't updating from .NET 5 -> .NET 6 on the nuget package require consumers to also be on .NET 6? Would think that since consumers need to make updates (if on .NET 5) to avoid a breaking change that would potentially be a reason to make it a major version. Jan 4, 2023 at 21:09
  • @DeveloperGuy See the last paragraph. If it's a package that consumers download and include in their systems, then probably. But if it's a web API that consumers interact with over HTTP, then no.
    – Thomas Owens
    Jan 4, 2023 at 21:15

Unless there is a change to the functionality of the code. Don't change the version number.

You can build your library to target multiple framework versions. The compiled dlls should all have the same version number, .net can tell what framework version each is for.

  • 2
    This contradicts one of the SemVer requirements: Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version. If you didn't support multiple versions and then updated the configuration to do so, the configuration file changes would trigger a version update. Also, if you need to make code changes to support a newer framework version, you would also need to update the version number. But if you are able to build against multiple frameworks with no changes to code or config, this would work.
    – Thomas Owens
    Jun 18, 2022 at 9:26
  • I really mean the major and minor versions, obs new build new version. However. Having said that, adding a target would produce an additional separate output. maybe you could release that separately without changing the previously released "packages". Although the standard in .net would be a nuget with all the frameworks included in a single package, rereleasing it with extra packages.. well it would be interesting to argue
    – Ewan
    Jun 18, 2022 at 11:55
  • Interesting. That does open some interesting arguments or perhaps edge cases if you include the optional metadata about builds, platforms, etc. and if that satisfies the "release as a new version" requirement.
    – Thomas Owens
    Jun 18, 2022 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.