(I suggested this a long time ago. It has also been suggested by other people, likely before me).

If you're shipping products with (non-developer) end-users who don't care about API changes, don't confuse them with raw semver, use vanity-semver!

<vanity>.<semver>

<vanity>.<major>.<minor>.<patch>

the change is simple: add a <vanity>. prefix that represents the version that end users should care about. most of the time this will just be 1.. But sometimes, when undergoing a fundamental product change (like OS X), it is useful to let end-users know that the thing is fundamentally better now, and that they should try it again. (or maybe it's even a sequel! \o/)

Basically, <vanity>. should change little enough to be safe to put in print. Yes, physical paper physically printed-on and shipped physically to analog humans. If it makes you uneasy to print + mail a version number to users, maybe use <vanity>..

It is recommended that end (non-developer) users see:

• ONLY <vanity> (or <vanity>.<major>) in marketing materials of any sort. (don't print 1.2.3... most non-developers won't care, and will likely confuse them... people will understand 1 and 2 though).
• the FULL <vanity>.<major>.<minor>.<patch> in error messages (which need to dump versions), and version/product information dialogs. (maybe even throw in a -<git-commit-prefix>). they need it easily available to communicate it to you and get support for the right build! (nothing is worse than getting stuck with phone support ... for the wrong product ...

Why? -- The problems with raw semver

semver is awesome and super useful. But it has one problem. things end up at high major version numbers (90.0.1!) pretty quickly.

The spec says:

Doesn't this discourage rapid development and fast iteration?

Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.

If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly?

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you'll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

Basically, release a breaking change once you're really, really sure of it (work on separate branches and only make few major releases! this fits github's API semver, which i think is still on V3. good responsible citizens! 👍).

I very much agree with TPW. But the reality is that people don't do this for the majority of projects... at all. modules all over the place (both libraries and programs) evolve very quickly, and sometimes a single deprecation causes a major bump. Which is the right thing to do when using semver. Major MUST be bumped. But this is often at odds with the intention of responsible developers with large non-dev audiences.

Ok, so we have a huge version number, so what?

That sucks for non-developer end users.

If you couple the API version (which is what semver is: a version of the API of the {module, program, restapi}...) to the "name version" of a product, things get really hairy. People don't want to deal with product names like "OS MCCXI (1211.1.2)" or "Chrome 43094321".

The disconnect comes from the fact that humans use version numbers to represent fundamental product changes to end users. This is completely decoupled from the API, actually. The old API might still be resepected, even after a logical change to the product version.

So, <vanity>. can give you a way to represent a logical increment on the whole product line.

Also, for big projects, reaching 1.0 should mean something. And you should be able to give people APIs with proper <semver> assurances before you have your 1.0 "ok you can trust me now" launch (right node?). And, at the same time, I don't buy this "oh just label it 0. at the beginning". If I'm consuming your code -- even alpha! -- i want to know when it has broken. Follow semver from the start. npm agrees and has been initing modules at 1.0.0 for a while now..