Have you seen the insane abuse that the Chrome (and later, Firefox) teams have subjected their version numbers to?
In the first ten years Firefox existed, it went from version 0.1 to version 5. They're completely meaningless concepts now. It is ludicrous we are now on major version >100 for both browsers!
> 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.
it simplifies versioning. there is no more major and minor versions. there is just version. how is firefox 108 any different from 10.8? it just feeds the argument when to make a major version bump if you don't just do it when you reach the 9.
it's something the linux kernel could have adopted too. because the difference between 5.19 and 6.0 is just as incremental as all the other versions.
the only benefit with the kernel versioning is that the first number gives you a rough indicator how old a system is. are you still on 4.x? you should probably upgrade. but actually the same can be done with current browser versions. your browser version is in the 80s? you should probably upgrade.
in the kernel case it would have been interesting to increase the major version exactly every 5 years to help with the age estimate.
as it is, the kernel settled on the version number being base 20
> it simplifies versioning. there is no more major and minor versions. there is just version.
Yep. For developers that build software its very easy. Fixed a bug - version++, improved performance - version++, changed API - yes version++, rewrite program in another language, broke all compatibility, remove 2/3 of all supported features, yep, version++.
By your logic difference between bugfix in programming language and change of syntax should be indicated with the same version++?
no, i only don't see the need to distinguish between major and minor feature releases.
there are feature releases and bugfix releases. this is what the linux kernel, browsers and even some linux distributions are doing.
for most apps but also for the linux kernel and for programming languages incompatible changes should not even happen. a browser should support old websites, so there is never an excuse to break compatibility. hence no need for versioning that. i am not talking about libraries and interfaces.
the main problem with major.minor versions is that it is never clear what should be a major version change and what should not. emacs solved the problem by simply dropping the major version. a few other applications did too.
the pike programming language switched from 0.6 to 7, avoiding calling it 1.0 as the language had already been stable for some time by then. then they slowly increased the minor version to 7.8 in 2008, but where afraid to go to 8.0. i remarked that if they didn't switch to 8 soon, they never would. eventually they switched to 8.0, 5 years later, and are now at 8.0.1738. (but there is a 9.0.0 version in the development branch since end of last year).
sbcl switched from 1.5.9 to 2.0.0 without any major changes. since then they release a new version every month and the version number is basically decade.year.month. there is no distinction between major and minor versions. the current version (looking at the calendar) should be 2.3.7. what does that tell me about the difference to 2.2.11? absolutely nothing. if they used a single linear increasing version it would not make a difference.
which in my eyes is actually correct for both examples because a programming language should not have major changes. the python2->3 transition was a big headache. it should not have been necessary.
in most examples that i can find the distinction between major and minor is meaningless. a more sensible distinction is: feature.bugfix, that's enough. and for many apps i would not even bother with bugfix releases unless the bugs are damaging to the users.
Have you seen the insane abuse that the Chrome (and later, Firefox) teams have subjected their version numbers to?
In the first ten years Firefox existed, it went from version 0.1 to version 5. They're completely meaningless concepts now. It is ludicrous we are now on major version >100 for both browsers!