Chrome and Firefox will reach version 100 in a couple of months. This has the potential to cause breakage on sites that rely on identifying the browser version to perform business logic. This post covers the timeline of events, the strategies that Chrome and Firefox are taking to mitigate the impact, and how you can help.
Just skip 9.
Obviously things shouldn’t break because of a simple version number, but at the same time why have they gone through major version numbers so quickly? IMHO major version numbers should only get bumped with significant and potentially breaking changes.
Version numbers are bumped fast for exactly the reason of breaking changes. This is also why Firefox offers an extended support version on the side.
sj87,
Going by this breaking version number logic, it would suggest the breakages have been accelerating, haha. But I honestly don’t recall firefox breaking APIs 7+ times every year, more like once every couple of years when they change/retire interfaces.
The ESR version is often preferred by linux distros because it does not (yet) force a walled garden for extensions and related anti-features. Sometimes you can end up between a rock and a hard place if you need the latest stable version plus 3rd party extensions because mozilla has decided not to allow it. I’ve been there, ugh…I find walled gardens regressive for FOSS projects. But in any case, developers like me on linux will typically end up with the ESR version while our end users typically end up running the latest regular version before we do, which is arguably the opposite of how it should be. Oh well, haha.
Why do you think it’s only about the APIs? There are user-facing features being dropped quite often — even the latest Firefox 97 did drop some.
But since you mentioned APIs, since Chromium is also the base for Electron (and Node.js), I’ve heard complaints that previously upgrading the underlying Chromium engine during regular updates introduced unexpected breakage for people building on top of the Electron frameworks. So there are definitely “breaking changes” in between browser engine releases even if not all of them are obvious or announced.
sj87,
It still seems excessive to me. I think cevvalkoala could be right that they are somewhat arbitrary, but it could be interesting to see a detailed analysis to get a better understanding of the justification for changing versions so frequently.
The version numbers are based on time, not on number of changes. It’s more of a date code than anything.
The version number race began because Chrome was a latecomer to the scene, and the hipsters on Chrome team decided that they should surpass the then market leaders IE and Firefox on every front, and quickly. Changing version numbers every three months allowed them to do that.
Soon, Firefox guys noticed that strategy, and duly applied it. Thanks to their incessant downwards slide in market share, we now know that, just like anything hipster, senselessly increasing version numbers does not bring any benefits.
The numbering scheme also reflects on the change in development models. Browsers used to be baked slowly and carefully, introducing a huge load of changes and improvements at once but leaving users begging for those critical improvements for months ahead. Even I used to run alpha versions of Firefox when their 3.0 and 3.5 and 3.6 versions were slow to be released.
What the Chrome folks actually started was developing the browser continuously, releasing new features once they were ready — and not only when a pre-planned set of multiple features actually was finalized. And I do believe that most common users are happier about the development model even if corporate users face some pain.
sj87,
IMHO it would be more informative to use a build date to distinguish installations in that kind of development model. Version numbers become rather meaningless if they don’t represent planned or distinct releases.
That’s a sensible approach. But alas, common sense is not so common nowadays.
True, given that the standards are more important than the browser per see. And when I say “standardized”, I mean it literally: it’s format is defined on RFC 1945 (the standard that’s not a standard, but where treated as a standard after release).
So, what we have here is legacy stuff made even more brittle by a actual registered standard. And a badly designed legacy stuff.
Targeting a specific client versions instead the standards versions that it’s based upon is bad practice. Worse, allowing a string such as that to even exist on the standard paved the way for years and years for all kinds of protocol violations and “vendor extensions” imaginable.
It’s appalling that as of today there’s no single way to communicate the specific HTML, CSS and JS standard supported by a browser, instead we send a very ambiguous long string of “compatible client versions” (that’s only getting longer and longer as more browser are released) and just hope for the best!!!
But Agent-String where standardized in a era where AGILE/SCRUM development models where not usual, engineering teams where smaller, and software releases used to be far slower moving.
Continuous development is good for the reasons you described. True, people wouldn’t flock to Chrome in the numbers they did, had Firefox been less lazy with the development.
On the other hand, development, by definition, will break compatibility. If asked to choose between the following two options, which one would you prefer?
Newest features added and added and added.
Old, sometimes abandoned, sites or add-ons continue working without a glitch.
The over-conservative guy I am would go with the second one, but that’s a personal preference.
If in 2022 some website are still struggling with 2 or 3 digit numbers, maybe, just maybe, they aren’t fit to survive in the Internet wilderness.
I pity humanity if “coders” can’t figure that out, especially with the previous cases that happened not too long ago. Only to save a few “bytes” ? The web with utf-8 and string “objects” that shouldn’t be an issue at all.
Should really history repeat itself on such a predictable occurrence ?
Is that like how I SHUDDER every time I see someone in the technical field write the year as “22”? HAVE THEY LEARNED NOTHING?? 😀
That you write “22” as a shortcut to “2022” is not completely stupid. The underlying storage format is still the same, be it dos or posix epoch (32 or 64 bits) and its resolution is plenty sufficient.
No, here it’s about version number management. I really favour the date-quarter thing, or just the plain build date. Not only you immediately know how outdated your software is, but it is way more meaningful than random increasing number like horse racing against each other at fast pace. Who’s gonna win, Chrome or Firefox ?
Silly me, not the users…
Powerful computers made us lazy and lowered the bar to become a professional coder.
And javascript happens to be a very forgiving language for stupidity that makes all too easy to shot itself in the foot, even easier then C that regard.
Text parsing and tokenization is classic compsci problem. But proper parsers demands knowledge.
Yes, the history will repeat itself.
The Y2K38 problem is closing in on us. Whilst it’s not going to be a problem with modern 64-bit software and hardware, there will likely a lot of 32-bit legacy hardware and software in production when 2038 rolls around. Whilst 16 years seems a long time away, it’s always good to be prepared, especially if you’re using legacy software and hardware for embedded and automation purposes. After all, the quantity of legacy systems that were affected by Y2K that are still in use today is frankly, terrifying.
It’s all not about dates, but version number. They obviously cannot even manage something that could be stored on a fucking single byte : 0-255
What a farce.