That has a lot to do with modern “agile” programming and similar changes in software development that have taken over in the last decade or so. Agile has much shorter release cycles than the traditional “waterfall” method of software development, which is what leads to the really high version numbers.
Agile programming works well for things like browser development. It allows developers to quickly release new features and gives you the most bang for your buck, so to speak.
The down side of these short release cycles is that you lose the idea that major changes would only be introduced when the major version number changed. The version numbers used to be (major).(minor).(bug fix), so you could tell from the version number how much things really changed. If your whiz-bang-spiffy software changed from version 1.6 to 1.7, you knew that there weren’t any major changes under the hood and you didn’t need to worry too much about software compatibility issues and such. But if your software changed from 1.7 to 2.0, you knew that major changes had been made, and you needed to be much more careful about things that could change compatibility or workflows.
Since the major version numbers now change very rapidly, all of that is gone. You can no longer tell by the version number whether or not a major change was done. A major change could come in between version 85 and 86, while versions 72 to 85 could all be minor changes, and 86 to 92 could all be minor changes. You can no longer tell by the version number change whether a change really was a major change or not…
Agile programming doesn’t require you to have silly high release numbers. But you can blame Google and Chrome for this becoming the standard for browsers. Google jumped on the agile programming bandwagon and decided to just constantly update their major version numbers. Firefox retained their older method of only changing major version numbers for a while (which you can easily do while using agile programming), but then it started looking like Chrome was being updated more frequently. Oh, look, Chrome is up to version 75 and Firefox is still back at version 11. Chrome must be better! (version numbers are for illustration of the point - I don’t remember what the version numbers were when each browser made the change)
So Firefox started using Chrome’s method of rapidly changing version numbers. And now the major version number is meaningless.
They also started putting the build number in with the version number, which is something that only matters to the developers. If you are doing multiple builds per day, the build number quickly gets to be rather large. The build number is very helpful for developers, since if a bug is in build 1456 but not in build 1455, then you only need to look at the patches that went in between those two builds to see which patch caused the bug. The build number is pretty much useless to anyone else though.
There is a lot more to agile programming than quick release cycles, but that’s a topic for a different thread. I’ve gone off too long on this hijack as it is,so back to our normal thread.