> There is a major difference: user-facing applications don't need to maintain backward compatibility.
Of course they do. Users still use extensions and web-pages that they expect to work. Firefox moving from e.g. XUL/XPCOM to WebExtensions could've been a major version bump, for example. Ditto Manifest v3 for Chrome.
I wish people would stop assuming users are too stupid to understand basic information about the software they use!
I feel that when an application stops supporting some old, unused file format that nobody cares about anymore (for example some old version of .doc files), then it should not be a major version bump. That would be giving too much visibility to a change that has little to no impact for most users.
Extension APIs on the other hand should have their own version number. Especially since an application may ship with both v1.x and v2.x for some time while v1 is being phased out. The app may even display some warning: "you are using extensions X, Y and Z that are using the API v1. This API will be removed in next release, causing these extensions not to work anymore".
The target audience of those version numbers is different from the app's main version number.
For a library or a language, developers like to use Semantic Versioning: a major update will break client code.