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.
Honestly I don't have an issue with Firefox/Chrome for the rapid version number increases. A browser is the most updated (or should be) bit of software on your computer. Honestly I don't even think of the version of Firefox or Chrome these days. They are just "Firefox" and "Chrome". This is much better for general users IMHO as it just means they use "Firefox" and not "Firefox 4.1.2" or whatever. A consistent update schedule makes a public version number pointless and it has, at least in my experience, made extension developers better at building extensions that don't break because I have upgraded from version 15 to 16 like we had back in the Firefox v2/3/4 years.
At the end of the day when the version number isn't really known to the end user it makes little difference if you bump up the major version number or the minor.
Also I love how quickly we get new features now. Firefox has improved more in the past year than it did in the past several years before the shift to a 6 week release cycle. It isn't suited to all software I admit but for a browser it is perfect. None of this "This site only works with Firefox XX or Chrome XX". Thank god!
> at least in my experience, made extension developers better at building extensions that don't break because I have upgraded from version 15 to 16 like we had back in the Firefox v2/3/4 years.
This is more caused by Firefox stopping to break the compatibility all the time. The plugin API in Firefox used to be just the internals, exposed to JS, so everytime something changed, it broke extensions. These days, they stopped doing that quite as often plus they published the Jetpack SDK which promises a stable API at the cost of less possibilities to change the browsers behaviour.
Meaningful versioning (aka "semantic versioning", http://semver.org/) isn't super important for an application. It's super important when dealing with libraries, of which libcurl is.
In what way is their version number scheme meaningful? They broke abi compatibility in the past without changing major version numbers and now they say they won't break the abi and compatibility and that's why they aren't changing major version numbers...
Where is the meaning? At least for Chrome/Firefox you know x+1 means another six weeks are over...
Firefox actually does break ABI compatibility with every release (for the minority of extensions that use binary code that links to Firefox libraries). So according to traditional version numbering dogma, Firefox is doing exactly the right thing by incrementing the major version number with every release.
