Version numbering - SemVer 2.0.0 compliance

[stefanluchian]

Type of issue

• [ ] Bug
• [ ] Enhancement
• [X] Compliance
• [ ] Question
• [ ] Help wanted

Current Behavior

Important code changes, like bug fixes, changes of behaviour and even changes in the interfaces, are sometimes visible only in the changing of the 4-th number in the version number, e.g. differences between 1.4.371.41 and 1.4.371.96. These important changes are not optimally detected by the nuget package manager of Visual Studio, which seems to pay attention only to the first three portions of the version numbers, like in SemVer 2.0.0.

Expected Behavior

Please comply with the SemVer 2.0.0 and use only major.minor.patch for the releases, so that the IDEs like Visual Studio can correctly detect the important changes. Important changes like the exponential backoff by the SessionReconnectHandler might be missed by some developers, because they think that should pay attention only to changes in the major-minor-patch part of the version numbers. So, someone who took e.g. version 1.4.371.41 will have different behaviour compared with a coleague that took 1.4.371.96, only because they both use "1.4.371" in the file package.config, but compile the solution at different moments in time.

Steps To Reproduce

No response

Environment

- OS:
- Environment:
    Visual Studio 2019
- Runtime:
- Nuget Version:
- Component:
- Server:
- Client:

Anything else?

No response

[stefanluchian]

According to Microsoft, the default option in Visual Studio for the installation of NuGet-Packages is "Lowest". But nowadays is not unusual, that developers change that default behaviour in Visual Studio, switching to "highest patch" or even to "highest minor", assuming that the behaviour of the package doesn't change dramatically or at least remains backward compatible.

[mregen]

Hi @stefanluchian, unfortunately we carry a baggage here, which is the spec version. The spec version is 1.04 or 1.05 next, so our first two digits are preset. An option were to make a 14 or 15. But the reference to a 1.3 or 1.5 spec version seems important. Then the next number is one that is increased when there is a 'breaking change', e.g. 371->372 The last number is the build number since the commit for the breaking change was updated. Imho there is currently no better solution, unless you have some idea.

[stefanluchian]

Thank you, @mregen , for your feedback. I didn't know about your preset digits. This situation, indeed, doesn't allow to comply with SemVer. In that case I would find very useful to write a warning in both the GitHub readme.md and in the readme/description of the package on nuget.org, in order to warn the users about the preset digits and that they shouldn't rely on the mechanisms of the IDEs (like Visual Studio) in order to get the version they need.