A little #Emacs#package I made to easily see what #semver constraints translate to in the echo area. For example to ensure that ~1.1.0 actually does translate to >=1.1.0 <1.2.0 and avoid mistakes!
@etenil Few people talk about a major disadvantage of Semver, often in a business context. But even FOSS suffered from it, e.g. Linus' Linux-Kernel.
The issue is the psychological distance in PMs, Marketing, etc to large Numbers. They don't like e.g. "foobar 3.325". And force an arbitrary rename. To "foobar 4.0" if you're lucky. Iignoring that nothing would mandate a Semver-conforming major number change). Or to, worse, "foobar 2025".
And they dislike a "foobar 420.1.0" even more.
So, technical Semver might be nice, but it ignores a human psychological aspect.
Personally I've had suits never mess with a versioning scheme. of YYYY-MM.n, where n is going from 1 up (not a day). That allows two releases in one day ("face palm release"). And it also removes the often not so easy decision of major number change. What e.g. is the API of a GUI program? And when is a change incompatible?
To suits, YYYY-MM isn't too large. And it transports some sense of "newness" (since they usually only have to do with the newest version). That makes this scheme suit-resistant.
And to document API changes ... use the changelog. You have docs, do you?
Add comment