Impact of the new 2-week release schedule on downstream fork integration

158 views
Skip to first unread message

Gediminas Veiverys

unread,
Mar 4, 2026, 9:13:32 AM (yesterday) Mar 4
to Chromium-dev
https://developer.chrome.com/blog/chrome-two-week-release

The two week release schedule potentially adds more strain to the integration and release cycle for chromium fork maintainers. I think is is true even with the extended stable cycle remaining unchanged.

1. Browser detection javascript run by many websites in many forms is going to be less forgiving as they rely on version checks at least in part. This is also something that is not going to be adjusted any time soon in a general sense, given the wide variety of implementations each site may run.

2. Captcha services will likely flag more often. These may be concentrated to a few big services and rely on a lot more data than just client version string, but they are difficult to address on the client side whey they do happen and I think more false positives can happen.

Other than matching the 2x release cycle speed increase, what's your comment or recommendation going forward to mitigate these potential problems?

Let's say (1) could be in theory addressed by adding to UA-CH
https://developer.mozilla.org/en-US/docs/Web/API/User-Agent_Client_Hints_API use cases.

<...>
* Blocking spammers, bots, and crawlers.
* New: Improving false positives rate for bot detection

Marshall Greenblatt

unread,
Mar 4, 2026, 12:33:25 PM (24 hours ago) Mar 4
to g.vei...@gmail.com, Chromium Embedders
(moving chromium-dev to BCC, adding embedder-dev to CC).

Thank you for raising this issue. Given the long tail of most release processes, I would hope that the majority of websites allowlist versions by time frame (e.g. anything released in the past 3 months). For Chromium embedders specifically, I don't think the majority will adopt a two week release cycle. For example, I've outlined CEF's options at https://github.com/chromiumembedded/cef/issues/4114.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/607d9a3e-11c9-4079-a2df-721994e82eben%40chromium.org.

Gediminas Veiverys

unread,
Mar 4, 2026, 1:55:53 PM (22 hours ago) Mar 4
to Chromium-dev, Marshall Greenblatt, Chromium Embedders, g.vei...@gmail.com
Yes, a well-behaved website should not be impacted, but not all website are like that. I think this change comes in two parts

1. If you choose to follow the new 2 week plan, then, well, you have that.
2. Or you can do every second release to keep the old pace, but then you are out of date more of the time than before. This includes both chrome version numbers and the features, both used for browser compat or bot detection.

Yngve N. Pettersen

unread,
Mar 4, 2026, 2:41:46 PM (22 hours ago) Mar 4
to chromi...@chromium.org
Hi,

I am afraid, Marshall, that you are mistaken about that; in fact, at Vivaldi (which is using Extended Stable) we generally start receiving reports issues about sites saying "You are using an obsolete browser, you must update to use this site" at least two weeks before the next Extended Stable is even available. Among sites where we think we have received such reports about, is Twitch, and I have myself seen lots of Cloudflare (and co) "Checking your browser" roadblocks once the Stable is two or three weeks old.

These sites are not using anything new. They are just blocking browsers based on their version numbers, calling them "outdated", "unsupported", "must update", etc..

Then there are sites like https://www.whatismybrowser.com/ that seems unaware of the existence of Extended Stable.

This problem is so severe for our users that we are now starting to seriously consider the possibility of spoofing the current Stable Chromium version, that is, UA and Client Hints would e.g. for a v144 show v145 instead to web sites.

IMO, an (extreme, hacky) method that Chrome could use to help mitigate this situation would be to send (in UA and Client Hints) the Current Extended Stable Chromium version number in a significant (>10%) of installed Stable installations to make sure that the sites don't dare to block Extended Stable browsers.

Another way the Chrome/Chromium team can help is by overlapping patch support for the old Extended Stable for 4 weeks after a new Extended Stable is release; that will help downstream embedders that are releasing a week or two after the Extended Stable release

Gediminas Veiverys

unread,
Mar 4, 2026, 4:06:13 PM (20 hours ago) Mar 4
to Chromium-dev, Yngve N. Pettersen
We are experiencing exactly the same with HP Secure Browser.
Reply all
Reply to author
Forward
0 new messages