[satvikpendem]

> Of course, I still find this nonsense far more preferable to the bullshit that is the Chrome Version System where the entire number means jack shit.

Why should it mean anything? It's just a succeeding number for every iteration, I find that vastly better than using dates or point based releases.

[Dalewyn]

Using a datecode shows immediately how old a given release is, which is useful information. I don't know how old Chrome 101 or Firefox 89 is; I know how old Windows 11 22H2 or LibreOffice 24.2 is.

Using a traditional Major.Minor.Revision.Build version number shows how much of the codebase is common between different versions. I can expect something made for one Major version to work in any other same Major version release, I can expect only a Revision or Build increment to include only very minor changes; likewise I can expect breaking changes between different Major versions. I don't know what Chrome 101 is other than it's after Chrome 100; I know NT6.0, 6.1, 6.2, and 6.3 are largely interchangable.

[amadeuspagel]

Chrome and Firefox are released so often that if the version number were a date it would have to include the day.

[cpeterso]

Including the day isn’t even enough because Mozilla actually releases two Firefox “Nightly” builds a day, one every 12 hours or so.

[satvikpendem]

For an end user product like Chrome or Firefox, the version number does not matter as much, it's really only useful for developers who might depend on specific versions.

[ozim]

This time and age I don’t believe anyone really depends on specific version of browser.

You could pull that maybe for a month. Longer than that and your customers will drag you through hot coals that you fix your stuff and move forward because you block security updates they need to install.

Unless of course you have it somewhere deep in company and it is IE8 app that no one can update.

But if you do anything public or SaaS platform you probably just fix stuff to support new versions or you are out of the game.