2

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 version or does bumping the minor 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.

Improve this question
12
  • 3
    Who is consuming that semantic version?
    – jonrsharpe
    Jun 17 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 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 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 at 10:20
  • 2
    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 at 11:19

2 Answers 2

Reset to default
6

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.

Improve this answer
1

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.

Improve this answer
3
  • 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 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 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 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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