I worked at a place where the version numbers were largely chosen by the CEO for marketing reasons. He'd keep them low for brand new stuff to excite the early adopters then bump the major version up a 5 or so when he wanted to sell to more conservative types.
I was, by chance, at a client once where they were having a big meeting discussing how much testing etc was required to make a "big" upgrade. I had to point out that, in fact, the difference between the 2 versions was a few minor bug fixes largely in code they didn't use.
They weren't very happy.
When I got back to the office I, somewhat tongue in cheek, suggested we allow the clients to choose their own versioning systems. I still think it would be better than what we had.
It's not that we have trouble with it-- it really is pretty simple. It's that there can be a bunch of rules around it that make it not simple.
For example, how do you evalute postfix addition? If you have v1.0.0-alpha3 and v1.0.0-alpha10, are all semver implementations supposed to do an alphabetical check until it sees a string? Or should you zero-pad anything with text postfixes? And how do you deal with labeling branches or architectures?
Internally, we no longer use semver, we use the build number as the version, and the commit hash as the input to the deploy systems.
> For example, how do you evalute postfix addition? If you have v1.0.0-alpha3 and v1.0.0-alpha10, are all semver implementations supposed to do an alphabetical check until it sees a string? Or should you zero-pad anything with text postfixes?
That's not semantic versioning. Semantic versions are for communicating feature additions and breaking changes to technical users. Alpha/beta are for marketing and communicating stability to nontechnical users.
If you're releasing to a large user base, there's no reason to do more than 1.0 alpha and 1.0 beta before 1.0. Releasing a ton of times before your big release causes a lot of deploy thrashing that's pointless. Unless your user base is truly gigantic, I'd even be hesitant to release an alpha.
If you're releasing personalized changes to a few clients, then alpha/beta don't make sense: they don't care about a general sense of reliability, they care about features they've requested, so just tell them, "This is the release with X feature you are interested in."
Internally, there will always be technical users who might fine use in semantic versioning. If you're doing alpha/beta, 1.0 alpha can be 1.0.5 and 1.0 beta can be 1.0.23 and 1.0 can be 1.0.75. Similarly, changes delivered to specific users can just be specific files earmarked for them.
> And how do you deal with labeling branches or architectures?
Why are you tagging branches with a version number? Version numbers are for stable, tested, cohesive, coherent code points, not for whatever random state exists in version control. If you're trying to map version numbers to your git tree, of course that doesn't work: git trees are complex. A semantic version should only ever correspond to a stable point in your "source of truth" branch. A version is a commitment that the versioned code point is something you're willing to support and put your name on.
There are a few ways to deal with different architectures. If you have architectures that are relatively synced and coming from the same codebase, just version them the same: 1.0.1 for Mac and 1.0.1 for Windows are the same, they're just different files from the same release. If your architectures are drastically different (Mac is far behind Windows, for example) then version them as separate products: 1.0.1 for Mac can release at the same time as 2.1.5 for Windows.
I was, by chance, at a client once where they were having a big meeting discussing how much testing etc was required to make a "big" upgrade. I had to point out that, in fact, the difference between the 2 versions was a few minor bug fixes largely in code they didn't use.
They weren't very happy.
When I got back to the office I, somewhat tongue in cheek, suggested we allow the clients to choose their own versioning systems. I still think it would be better than what we had.