This was motivated by the cockroachlabs’s decision to switch to a calendar versioning. Their problem is that they want to signal a major change in features, but they do keep their backwards compatibility. For a lay-person, the major version number signals capability, and it is not encouraging when that does not change.
From what I can see, there are two main uses for versioning – one to determine whether a given version introduces breaking changes to an existing API, and another to specify an increase in capability. I wonder if explicitly tagging them as such, with no ordering specified would help resolve the issue. The idea is to tag the major version with
C (for compatibility) and minor with
F (for features). (Perhaps
P for patches too for software like Latex or algorithms that are not expected to change in functionality.)
F2.C1.P0 signals that We have a significant improvement over
F1.C1.P0. It is exactly same as
C1.F2.P0. On the other hand
F3.C2.P0 signals that the API changed when compared to
F3.C1.P0. Indeed, the developers may choose to increment the
F part also when breaking changes are introduced. It can be converted to the semver 2.0 format by simply splitting by
. sorting, and stripping the first alphabet.