SemVer is great for versioning APIs and the libraries that expose them, but very poor for versioning complex user-facing apps that are composed of many parts.

SemVer is great for versioning APIs and the libraries that expose them, but very poor for versioning complex user-facing apps that are composed of many parts. Do you increment the major version when you have a backwards-incompatible change in the Javascript engine? In the layout engine? In the DOM API? In the preferences storage format? In the plugin API? How about if you completely remade the UI (which could be argued is the "average user's API"), but kept all the programming APIs the same? Each release of Firefox is a composite of many parts, each of which may or may not have breaking changes. I think that what Chrome (and later Firefox) ended up doing is a pretty good compromise. The major version of Chrome is basically "Chrome" - if they ever break compatibility in any kind of major way, it probably will be as a different project. Firefox is the same way. I know that it'd be great if you could derive deep secrets about the changes in each release from just the version number, but that just doesn't scale to complex projects. Use SemVer and similar schemes where they're appropriate, but don't treat them like they're the only right choice.