Chrome halved the gap.
From Chrome 153 on 8 September, a new stable Chrome ships every two weeks instead of every four, on desktop, Android and iOS. For most sites that is nothing. For a screen bolted to a wall in a venue, it doubles the number of browsers your build has to survive in a year.
Google shipped Chrome 153 on 8 September and, with it, a change to how often Chrome arrives. A new beta and stable version now ships every two weeks rather than every four, across desktop, Android and iOS. Extended Stable, the track most enterprises are on, stays on eight weeks. That is the whole announcement, and if you build ordinary websites you can stop reading, because nothing about your week changes.
We do not only build ordinary websites. A good part of what we install runs in a browser that nobody ever looks at. A wayfinding screen in a foyer. A queue display above a counter. A tablet at a check-in desk that boots into one page and stays there for two years. For those, the release cadence is not a developer convenience, it is a maintenance schedule somebody has to own.
Thirteen becomes twenty six.
Chrome has shipped a milestone every four weeks since 2021, which is roughly thirteen versions a year. Halve the interval and you get roughly twenty six. The change in each one is smaller, and Google's argument is a fair one, that smaller releases are less disruptive and easier to debug after the fact. That holds when the thing running the browser is a laptop a person uses and updates without thinking.
It holds less well when the browser is part of a fixture. An installed estate does not fail on the version you tested. It fails on the one that landed three weeks after handover, on a Sunday, while the client's venue was full. The cost is never the fix. The cost is the site visit, the ladder, and the hour the screen sat there showing something wrong in front of paying customers.
What we are changing.
Nothing dramatic, and none of it is new thinking. The cadence just moved the deadlines closer together, which is a good enough reason to write the rules down.
- 01Installed work goes on Extended Stable, and it is a line in the spec, not a decision somebody makes on the day. Eight weeks is a cadence a maintenance window can actually match.
- 02Accept that Extended Stable means running behind. You are testing against a feature set the open web moved past weeks ago, so the build targets what is settled rather than what landed last fortnight.
- 03The regression pass runs on a schedule, against beta, not once before handover. A screenshot diff and a scripted walk of the three things the screen has to do, on the version that is coming, is cheap next to a call out.
- 04Every device can roll back, and somebody has tried it. An update channel with no way home is not a channel, it is a hope.
- 05Prefer the boring platform feature. Interop 2026 exists because the browser makers agreed to converge on the same behaviour, and the parts of the platform they have all settled on are the parts that will still behave in March.
The quiet argument for the web.
It would be easy to read a faster cadence as a reason to stop putting installations in a browser. We read it the other way. A platform that can ship a security fix to a screen in a foyer inside a fortnight, without an app store review and without a technician on site, is doing something no native install does as cheaply. The price of that is a shorter leash on testing, and the discipline that comes with it.
If you have something of ours on a wall, this changes nothing you need to act on. It changes what our update window looks like, and we would rather say that out loud than have it turn up as a surprise in a quarter's time.