All too often, I see people people pointing out flaws in Semantic Versioning (SemVer), or pointing out that it doesn't apply to huge categories of software. (See quotes below).
- SemVer doesn't apply to websites without a public API.
- SemVer doesn't apply to stand-alone applications without a public API.
- SemVer doesn't apply to internal development branches, only "releases".
SemVer is ... is also not perfect and has problems, and while advocates of SemVer seem to think it is the holy grail, there are reasons not to use, and many project in fact don't. An answer claiming that only SemVer exists misses a gigantic part of the landscape out there. – Polygnome
you should in principle not use ... semver ... Applying this versioning scheme to content ... it could be easier to fork it to create your own versioning scheme, tailored to content ... -- Christophe
Two version versioning schemes are in use. ... Semantic Versioning, or SV ... Date Versioning, or DV ... Older compilers, which only use SV, ... ... -- "Compiler Version Numbers and What They Mean"
Like an operating system, Twisted has a lot of parts, making SemVer a poor fit ... -- Calendar Versioning (CalVer)
the state of "Semantic" Versioning, and why we should be fighting the good fight against it. ... -- jashkenas
OK, so SemVer isn't ideal for my project - how do I choose a different scheme which is more appropriate? Of course, this boils down to some kind of requirements analysis for my specific project. However, I suspect versioning isn't something overly complex, so a few criteria or rules-of-thumb should be sufficient to make a decision. I hope one of the communities' experts can contribute a short writeup or checklist how to approach this.
Or maybe there are well-defined versioning systems different from SemVer which allow me to choose from for at least some projects?
(I'd be happy to learn about such systems even if such a system is clearly worse than SemVer for other projects).