Chrome, Edge and Firefox now ship every two weeks: what extension developers should change

For years, extension developers could count on a new major browser version roughly once a month. That rhythm is gone. Between late August and early September 2026, Microsoft Edge, Firefox and Chrome all moved their stable channels to a two-week release cycle. Your extension now runs on a browser that changes twice as often, on three different calendars.

The browsers are not shipping twice as many changes. They are shipping the same stream of work in smaller batches. But every batch is a chance for something your extension depends on to behave differently, and you now get half the time between them to notice. This post covers what changed in each browser, what it means for extensions, and a practical setup to catch problems before your users do.

Key takeaways

• Edge moved to two-week stable releases with Edge 152 on August 27, 2026, Firefox with Firefox 155 on September 1, and Chrome with Chrome 153 on September 8.
• Each release is smaller, but there are twice as many of them. Test against Beta continuously instead of once a month.
• Extended Stable in Chrome and Edge stays on an eight-week cycle, so enterprise users now sit further behind the newest version than before.
• Browser updates can break an extension without you shipping anything. Watch your reviews after every browser release, not just after your own.

What changed, browser by browser#

Chrome#

Google announced the change in March on the Chrome for Developers blog in Get features faster with Chrome's two-week release cycle. A new Beta and Stable version now ship every two weeks on Desktop, Android and iOS, starting with Chrome 153. The Dev and Canary channels are unchanged, and Extended Stable stays on its eight-week cycle for enterprises and Chromium embedders. Chrome 154 followed on September 22, as 9to5Google reported.

This is the second time Chrome has shortened its cycle. It moved from six weeks to four in 2021.

Microsoft Edge#

Edge actually went first. In the Microsoft Edge blog announcement, Microsoft described each release as containing about half as much new content as before, delivered twice as often. Extended Stable now receives every fourth Stable release (156, 160, 164 and so on), which keeps it on the same eight-week interval. Microsoft's advice to IT admins is to put a pilot group on Beta and start testing from day one, which is good advice for extension developers too.

Firefox#

Mozilla moved Firefox Desktop and Android to two weeks starting with Firefox 155 on September 1. The Mozilla Support team's post on the new release cadence stresses that this does not mean Firefox will ship twice as many features, only that updates arrive more often on a predictable schedule. As The Register reported, Mozilla's engineering leadership framed the change as an experiment, so the cadence could still be revisited.

The next few releases#

Here is the upcoming calendar as published by each vendor at the time of writing. Planned dates can move, so treat the official schedules as the source of truth: the Chromium Dash schedule, the Microsoft Edge release schedule and Mozilla's Firefox release calendar.

Two things stand out. First, there is now a stable release of at least one major browser almost every week. Second, each Beta is available roughly two to three weeks before its stable release. That Beta window is your testing window, and it is shorter than it used to be.

What the new cadence means for extensions#

Regressions arrive more often, but smaller#

A browser release can break an extension without you touching your code: a changed API behavior, a new permission prompt, a tightened content security rule, a bug in a new build. With smaller releases, any single one is less likely to break you, but there are twice as many chances. The practical effect is that "check against the new browser" stops being a monthly task and becomes a continuous one.

The upside is real too. When something does break, the list of changes in that release is shorter, which makes the cause easier to find.

Version numbers stop meaning time#

Many teams write support policies as a number of versions: "we support the last three Chrome versions." Under a two-week cycle, three versions covers six weeks instead of twelve. Express support windows in time ("anything released in the last three months") and translate them to version numbers when you need them.

The gap to enterprise users gets wider in versions#

Extended Stable in Chrome and Edge still updates every eight weeks, but stable now moves four versions in that time instead of two. If your extension has business users, the spread of browser versions you need to support just grew. Before you rely on a new API, check that it exists in the Extended Stable version too.

Deprecations and removals land on a finer grid#

Browser removals are tied to milestones. Chrome already removed the --load-extension command line flag from branded Chrome builds in Chrome 137, for example, which broke many extension test setups overnight (see the Chromium extensions PSA). With more milestones per year, a removal announced for "version N" arrives sooner in calendar terms than the same number would have implied last year. Recalculate the dates of any deprecation you are tracking.

A testing setup for two-week browsers#

The goal is simple: run your extension against the next browser version before it reaches your users, every time, without anyone having to remember.

1. Test Chrome Beta in CI#

Since Chrome 137, branded Chrome builds ignore --load-extension, but Chrome for Testing still loads unpacked extensions, and Puppeteer can install a specific channel of it. The Chrome for Developers Puppeteer guide loads an extension with the enableExtensions launch option:

import puppeteer from 'puppeteer';

const EXTENSION_PATH = new URL('../dist', import.meta.url).pathname;

const browser = await puppeteer.launch({
  // Point at a Chrome for Testing build of the channel you want to test.
  executablePath: process.env.CHROME_PATH,
  headless: false,
  pipe: true,
  enableExtensions: [EXTENSION_PATH],
});

// Wait for the extension's service worker, then run your checks.
const worker = await browser.waitForTarget(
  (target) => target.type() === 'service_worker',
);

Then run the same test suite against two channels, so a Beta failure shows up next to a green stable run:

# .github/workflows/extension-e2e.yml (excerpt)
strategy:
  fail-fast: false
  matrix:
    channel: [stable, beta]
steps:
  - uses: actions/checkout@v4
  - run: npm ci && npm run build
  - name: Install Chrome for Testing (${{ matrix.channel }})
    run: |
      CHROME_PATH=$(npx @puppeteer/browsers install chrome@${{ matrix.channel }} --path .browsers | tail -n 1 | cut -d' ' -f2-)
      echo "CHROME_PATH=$CHROME_PATH" >> "$GITHUB_ENV"
  - run: xvfb-run --auto-servernum npm run test:e2e

Run it on a schedule as well as on every push, for example twice a week. A new Beta can break you on a day when nobody has committed anything. The end-to-end testing overview also covers Selenium and WebDriverIO if you prefer those.

2. Cover Firefox with web-ext#

For Firefox, Mozilla's web-ext tool lints your package and can launch a specific Firefox build with the extension loaded:

npx web-ext lint --source-dir dist
npx web-ext run --source-dir dist --firefox /path/to/firefox-beta

Keep a Firefox Beta install on at least one team machine or CI runner and point --firefox at it. The Firefox Beta for each release opens about two weeks before it ships.

3. Smoke test Edge Beta by hand#

Edge is Chromium based, so a passing Chrome Beta run catches most problems. Edge still has its own features and policies, though, so keep Edge Beta installed on one machine and give it a five-minute smoke test in the week before each Edge stable release: install, open the popup, run the core action, check the options page.

4. Feature detect instead of checking versions#

The more often versions change, the worse version sniffing ages. Check for the API you need instead:

// Works on any browser version that has the API, and degrades on the rest.
if (chrome.sidePanel?.setPanelBehavior) {
  await chrome.sidePanel.setPanelBehavior({ openPanelOnActionClick: true });
} else {
  await chrome.action.setPopup({ popup: 'popup.html' });
}

Chrome now also supports the browser global namespace used by Firefox, as announced in the I/O 2026 extensions recap, which removes one more source of per-browser branching.

5. Set minimum versions with care#

It is tempting to bump minimum_chrome_version (or strict_min_version in Firefox's browser_specific_settings) whenever you adopt a new API. Be careful. According to the manifest documentation, users on older Chrome versions see "Not compatible" instead of an install button, and existing users below the minimum silently stop receiving updates. With Extended Stable users now four versions behind, a minimum set to "last month's Chrome" can quietly freeze a meaningful slice of your business users on an old build.

{
  "minimum_chrome_version": "150",
  "browser_specific_settings": {
    "gecko": {
      "id": "[email protected]",
      "strict_min_version": "140.0"
    }
  }
}

Only raise the minimum when the extension genuinely cannot work without the new API, and prefer feature detection when it can degrade gracefully.

Watch the store after every browser release#

Testing catches what you can predict. Real users catch the rest, and they report it in store reviews. After the switch to two-week releases, a sudden cluster of complaints is as likely to follow a browser update as one of your own releases.

A simple routine:

1. Keep the browser release calendar next to your own. When reviews spike, the first question is whether a browser shipped that week.
2. Read new low-star reviews for browser mentions. "Stopped working after the update" on one store only, with no release from you, usually points at the browser.
3. Compare stores. A complaint that appears only on Edge Add-ons or only on Firefox Add-ons narrows the cause to one engine. Our guide to tracking one extension across Chrome, Edge and Firefox shows how to line the listings up.
4. Check the rating trend, not just today's number. The habits in reading review and rating trends apply here: a small dip on a low-volume store can be noise, a steady slide after a browser release is not. This matters more now that the Chrome Web Store rating favors recent reviews, so a week of browser-related complaints weighs more on your stars than it used to.

Extenify captures every listing daily, so an Unusual burst of new reviews, a string of New review lines or a Rating dropped change lands in your digest the day after it happens, whether the cause was your release or the browser's. If you have not set that up yet, start with store change alerts your team will actually read.

Your own release rhythm#

Faster browsers do not mean you need to ship faster. They do change when it is safest to ship. Avoid publishing a major version of your extension in the same few days as a stable browser release, so that if something breaks, you know which change to blame. And after your own release, keep following the checklist in what to watch in the week after an extension release, which now overlaps with at least one browser release every time.

Frequently asked questions#

Do I need to release my extension every two weeks now?#

No. The browser cadence does not change what the stores require from you. What changes is how often you should verify that your current version still works, which is why automated Beta testing matters more than release frequency.

Does the Extended Stable channel still exist?#

Yes. Chrome and Edge both keep an eight-week Extended Stable channel for managed environments. Edge Extended Stable now takes every fourth Stable release. Firefox keeps its separate ESR.

Is Firefox's two-week schedule permanent?#

Not necessarily. Mozilla's engineering leadership described it as an experiment and plans to assess its impact on release quality, developer workload and user experience before deciding whether to keep it.

How far ahead can I test a new browser version?#

Each Beta is typically available two to three weeks before the matching stable release. Chrome Dev and Canary, and Firefox Nightly, give earlier previews if you want more warning, at the cost of more noise.

Why do my extension tests fail to load the extension in Chrome?#

Since Chrome 137, branded Chrome builds ignore the --load-extension flag. Use Chrome for Testing or Chromium, or Puppeteer's enableExtensions option, as shown above.

Summary#

Three browsers, one cadence: a new stable version from somebody almost every week. The changes are smaller, but they come twice as fast, and the Beta window to catch problems is shorter. Test against Beta automatically, express support windows in time rather than versions, be conservative with minimum versions, and watch your store reviews after every browser release, not just after your own. Set it up once and the new rhythm becomes background noise instead of a monthly surprise.

Image credits#

• Cover photo: Drawing Pin on Calendar by Towfiqu barbhuiya on Pexels, Pexels License.