We have somewhat fallen into using non-semver versioning for GHFVS, mainly because CLR versions are 4 digits and our tools for incrementing our version number by default increments the last digit.

Here's my proposal for how we should use server for versioning with 4 digit version numbers:

• MAJOR for major changes in the way the extension works or is architected
• MINOR for features
• PATCH for bugfixes
• FUDGE is the last number and should usually remain at 0. The exception to this will be for situations like with the release of VS2017 RC where we needed to go back to an older version to make a minor tweak for inclusion in the VS installer.

In the case of the VS2017 RC release, we had prepared 2.1.1.4 for release with the VS installer, then released 2.1.1.5 when we were asked to make a change to 2.1.14, which became 2.1.16, breaking the update path to 2.1.1.5. Using this new scheme scheme, we would have had:

2.1.4.0 - Version for VS installer
2.1.4.1 - Update for VS installer
2.1.5.0 - Next release

In this way, monotonic versioning would have been preserved.

Note that this change should come into effect for 2.3.