Every major browser starts shipping every two weeks this month, and it quietly doubled the speed of every deprecation you were tracking

Between August 27 and September 8, a twelve-day window, every browser that matters changes how often it ships.

• Microsoft Edge 152 shipped August 27, 2026, the first Edge Stable release on a two-week cadence.
• Firefox 155 ships September 1, 2026, the first of Mozilla’s biweekly releases.
• Chrome 153 ships September 8, 2026, Chrome’s first two-week release.

Three vendors, two rendering engines, one calendar fortnight. None of them coordinated it publicly. Google announced in March, Microsoft in June, Mozilla in July, and the dates landed on top of each other.

Read the announcements and this sounds like plumbing. Users get features sooner, each release is smaller, nothing to see. That is mostly true, and if you run a small business website the correct amount of work this creates for you is close to zero. But there is one second-order effect that is genuinely worth ten minutes of your attention, and almost nobody is writing about it.

Milestone numbers used to mean time

For the last five years, a Chrome milestone was roughly a month. Chrome moved from six-week to four-week releases in 2021 and stayed there. That made version numbers a usable unit of time. When a vendor said “this API is removed in Chrome 155,” everyone doing the mental arithmetic converted milestones to months without noticing they were doing it.

Every deprecation notice, every intent-to-remove, every enterprise policy sunset written in the last two years is phrased in milestone numbers. And those numbers now arrive twice as fast in wall-clock time. Chrome ships 26 stable releases a year instead of 13. So does Edge. So does Firefox.

This is not theoretical, and we have already been bitten by it in print. When Google announced that Chrome would show a full-page warning for sites that cannot answer over HTTPS, the announcement put the change at Chrome 154 in October 2026, and essentially every article written about it repeated October. Then the cadence changed underneath it. Chrome 154’s stable date is now September 22, 2026. The version number did not move. The date moved by more than a week, and the only way to know was to check the schedule rather than the announcement. We covered the corrected timeline in the post on Chrome’s HTTPS warning.

The same thing happened to the unload deprecation, which reaches 100 percent of Chrome page loads at Chrome 154 on the same day, and whose rollout table had to skip milestone 153 entirely to keep the intended four-week spacing between steps. We wrote that one up separately in the post on unload handlers.

So the action item, if you take one thing from this: anything on your roadmap expressed as a browser version number needs to be re-dated. Not re-planned, re-dated. Go look up the actual stable date rather than assuming a month per milestone. The Chromium release schedule publishes them; so does Microsoft, in the Edge release schedule table; so does Mozilla, in the Firefox release calendar.

The schedules, so you do not have to look them up

Chrome, from Chromium’s own release schedule:

Edge, from Microsoft’s published release schedule. Microsoft commits to a release week rather than a day:

Firefox, from the Mozilla release calendar:

Two things fall out of putting them side by side. Edge sits roughly one milestone behind Chrome despite sharing the engine, so a Chromium change reaches your Edge users about two weeks after your Chrome users. And across the three of them there are now 78 stable releases a year, which works out at a browser release somewhere in the world roughly every five days.

What does not change

Worth saying clearly, because the coverage of this has been more alarmed than the facts warrant.

Features are not being rushed. Mozilla was explicit: “this doesn’t mean Firefox will ship twice as many features.” The two-week cycle changes how often stable builds are cut, not how fast an individual feature moves through development. Something that is not ready waits for the next train, and the next train is now two weeks out instead of four, which is precisely the point. Google’s framing is the same: releases are more frequent but smaller in scope, which makes post-release debugging easier, not harder.

Security updates were already faster than this. Chrome has shipped security fixes weekly since 2023, independent of the milestone cadence. The two-week change is about feature delivery. Nobody is getting patched faster or slower because of it.

Your test suite is probably fine. The most commonly predicted problem, that CI breaks because ChromeDriver no longer matches the installed Chrome, was mostly solved before this was announced. Selenium’s David Burns wrote it up in March under the title “why Chrome’s new cadence is a non-event for Selenium users”: Selenium Manager, bundled since Selenium 4.11, detects the installed browser version, resolves the matching driver through the Chrome for Testing endpoints, and caches the binary. His line is the right attitude to have about it: “You shouldn’t be a ‘Binary Manager’; you should be a Test Engineer.”

The caveat is the obvious one. That only holds if you are on a modern version. If your CI pins a ChromeDriver version by hand in a Dockerfile, or your test runner is old enough to predate automatic driver resolution, you will now hit that maintenance chore 26 times a year instead of 13. The fix is to stop pinning by hand, and this is a reasonable prompt to finally do it.

Nothing changes for the average visitor. Chrome, Edge and Firefox all auto-update. Your customers will not notice, and neither will you, which is exactly why the deprecation-date shift is the part worth tracking.

What does change, if you manage computers

This is where a real decision exists, and it only applies if you run managed Windows or Mac machines.

Both Chrome and Edge offer an Extended Stable channel that stays on an eight-week feature cadence while the regular Stable channel moves to two weeks. It is not a separate application and it is not a slower security posture in principle: security fixes and critical updates continue to arrive on their own schedule, back-ported into the extended branch. Edge documents that Extended Stable releases are published every fourth Stable release, so an organisation starting on Edge 152 next moves to 156, then 160.

The support windows are the part people miss. Microsoft publishes them plainly:

An individual Edge Stable release now has roughly six weeks of assisted support, down from what a four-week cadence gave you. If your process is “wait a month, then evaluate,” you are now evaluating a version that is halfway through its supported life.

To switch Edge, the Group Policy path is Computer Configuration > Administrative Templates > Microsoft Edge Update > Applications > Microsoft Edge > Target Channel override, set to Enabled, with “Extended Stable” selected. For Chrome, it is the TargetChannel policy, available for managed devices on Windows and Mac only; there is no Extended Stable on iOS or Android.

Before you reach for it, read the caveat Google puts on its own page: Extended Stable gets weekly security refreshes, but complex changes or large features that improve security might only be available on Stable, and Google states that the two-week Stable option remains the most secure choice. That is an unusually direct thing for a vendor to say about its own enterprise option, and it should be taken at face value.

Our read, for the size of business we work with: if you have fewer than a few dozen machines and no line-of-business web app that breaks when a browser updates, stay on Stable. Extended Stable exists to solve a validation-capacity problem. If you do not have a validation process to protect, opting into a slower feature channel buys you nothing and costs you the security posture Google just told you about. If you do have a fragile internal app pinned to browser behaviour, Extended Stable is the correct tool, and it is also a signal that the app needs work.

There is a third option that is better than both for most people: put a small pilot group on Beta. Chrome now ships Beta three weeks ahead of Stable, and Microsoft’s own guidance is to run a pilot group on Beta or Enterprise Preview so issues surface before the fleet gets them. Two machines on Beta is a cheaper insurance policy than an entire fleet held back eight weeks.

The thing that genuinely gets harder

The honest downside is not stability, and it is worth being precise here, because the easy version of this claim is wrong and we have written the easy version ourselves.

The spread of browser versions in your audience did not get wider in calendar terms. Extended Stable was eight weeks behind Stable before September and it is eight weeks behind Stable now. An organisation deliberately holding back is holding back by the same two months it always was. What changed is that those eight weeks now span four milestone numbers instead of two.

That reads like a distinction without a difference until you notice how much practical reasoning is done in version numbers rather than dates. “Our users are within two versions of current” used to describe an eight-week window and now describes a four-week one. Support matrices written as version ranges silently halved in duration. Analytics that bucket by major version now show twice as many buckets holding half as many people each, which makes a small-but-real compatibility problem harder to spot. And “we tested it in Chrome” does have a shorter shelf life, because the build you tested is superseded in two weeks instead of four.

For a marketing site this is noise. For anything app-shaped, it is an argument for two habits that were always good practice and are now closer to mandatory: feature-detect rather than version-detect, and treat field data as the source of truth rather than your own machine. If you have any code that reads a browser version number out of the user agent string and branches on it, this is the month it starts making decisions it was never designed to make.

Mozilla flagged a related second-order effect that is easy to miss: on a typical Firefox release they see an average 30 percent increase in incoming support questions in the first ten days. That wave now arrives every two weeks instead of every four. If you run support for a product with a web front end, your “is it us or is it the browser” triage load roughly doubles in frequency, even though the total volume does not change much. Knowing that in advance is most of the battle.

What to do about it

For a small business with a website and a handful of laptops, the whole response fits in a short list:

1. Re-date anything on your list that is expressed as a browser version. Look up the real stable date. Do not convert milestones to months. This is the entire point of this post.
2. Leave auto-updates on. For everyone. This has not changed and it is still the single highest-value browser decision available to a small business.
3. Do not opt into Extended Stable by default. Only take it if you have a specific app that needs validation time, and know that you are trading away some security improvements for that time.
4. If you manage machines, put one or two on Beta. Three weeks of warning for the cost of two devices.
5. Stop pinning browser versions by hand in CI. Let the tooling resolve drivers. You will hit this chore twice as often now.
6. Check the two things landing on September 22. Chrome 154 brings both the full-page HTTPS warning and the end of the unload rollout. Neither is caused by the cadence change, but the cadence change is why they are arriving sooner than the announcements said.

That is the whole job. The cadence itself is a non-event. The dates moving underneath the version numbers is not, and it is the kind of thing that costs you a surprised afternoon in October if nobody checked in August.

If you are not sure what your site or your fleet is exposed to here, get in touch. Working out which browser changes actually touch a given business is usually a short conversation.

Sources

• Get features faster with Chrome’s two-week release cycle, Chrome for Developers, March 3, 2026, by Ben Mason and Deepak Ravichandran, for the Chrome 153 start date, the Beta lead time, and Extended Stable staying at eight weeks
• Chrome release schedule, Chromium Dash, for Chrome 152 to 157 stable dates
• Faster updates, enterprise-friendly schedule: the new Microsoft Edge release cycle, Microsoft Edge Blog, June 11, 2026, for Microsoft’s pilot-group guidance
• Microsoft Edge release schedule, Microsoft Learn, for the Edge 152 to 157 release weeks
• Microsoft Edge Lifecycle Policy, Microsoft Learn, for the six-week and sixteen-week support and servicing windows
• Overview of the Microsoft Edge channels, Microsoft Learn, for the Extended Stable opt-in Group Policy path and the every-fourth-release cadence
• Extended Stable channel, Chrome Enterprise and Education Help, for the TargetChannel policy, platform limits, and Google’s note that two-week Stable remains the most secure choice
• Firefox release cadence experiment: moving to 2 weeks starting in September, Mozilla dev-platform, by Sylvestre Ledru, for the Firefox 155 date and the experiment framing
• Firefox new release cadence and what to expect, Mozilla Support Blog, August 19, 2026, for the feature-volume clarification and the 30 percent support-question figure
• Firefox release calendar, for Firefox 155 to 160 release days
• The two-week Flutter: Why Chrome’s New Cadence is a “Non-Event” for Selenium Users, Selenium blog, March 10, 2026, by David Burns, for Selenium Manager and driver resolution