"Unfortunately, your browser is too old to work on this site. Please upgrade your browser to view rich content, log in and reply."

But without cookies do you have to enter your password every time you want to post to a forum?

I do appreciate that level of security for websites involving monetary transactions, like those for banks, insurers, and utilities. But for a message board that would be a deal breaker.

DuckDuckGo lets you save cookies from certain sites. They call it Fireproofing a site. You open a site and Fireproof is in the menu options.

It’s similar to other browsers that let you select cookies to save.

I have the SDMB anf The Guardian saved so I don’t have to log in.

Damn, Firefox 88 ain’t even that old!! Even though I don’t really care about the redesigned UI of newer versions of FF, the fact that 88 is already obsolete is crazy. When was that, like a year ago?

Wikipedia says April 2021, so yeah, pretty much.

Remember when software versions rarely reached double digits? Now we have things at v.109.5.2351.056

/Pepperidge Farms

There was a cultural change. People decided updating the first number only rarely meant mostly just ignoring it. So might as well skip it.

I blame millennials. :wink:

Yes, the bad old days of IE9.

Every last “virus” infected every last computer.
It was not uncommon to find browsers with 100’s of “extensions”. Weekly or so Automated updates of browsers has saved the internet.

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.