Comment by necovek
I can see how you are using the multiple versioning schemes to achieve certain goals, but that does not make your approach "one true way".
"Semantic" really means "has some background meaning", and SemVer meaning behind all the numbers is in no way limited to API versioning: I am confused if you are making a proposal to consider it only that, arguing that different schemes should be used for different types of software, or stating that this is the only thing SemVer can be used for?
On any of those points, I disagree and you haven't made a convincing argument why that would make sense.
Note that I am not saying that SemVer is the only true way to do versioning (very much not so) for all software, just that it depends on your release strategy what is most applicable, and not on the type of software you are shipping.
The original reasoning behind Semver was that it described the changes from the point of view of the consumer of the interface. If the interface didn't change, then the semver didn't change.
So yes, I am arguing it should not be used beyond that.
Horses for courses... semver is about semantic meaning to the consumer of an interface, release versioning is about configuration and SRE, user versioning is about functionality and (for a client app) security.
As for proposing the "One True Way", no, I'm not proposing that, I'm saying that I use 3 different versioning strategies for 3 different use cases.
In a production system that I am involved with, the current production is:
API: v5.0.0 (yes we just introduced major breaking changes, however, we have an endpoint for older semvers)
Release: v2025-10-30 (with release notes saying which API Semvers were available and which versions of the user app)
User app: v3.5.1 (there was a security patch to v3.5)