A faster cadence starting September 1
Mozilla is cutting Firefox's release cycle in half. Starting with Firefox 155 on September 1, 2026, both Firefox Desktop and Firefox for Android move from a four-week release schedule to a two-week one, the first change of this kind to Firefox's cadence in more than a decade. Firefox 154, which shipped August 18, was the last release on the old monthly schedule.
The shift brings Firefox in line with its two biggest rivals. Google announced a two-week cycle for Chrome back in March 2026, framing it around getting security and performance fixes out faster. Microsoft's Edge, which is built on the same Chromium engine as Chrome, adopted a matching schedule of its own with Edge 152 on August 27, just days before Firefox followed. Firefox's move is notable specifically because it runs on Gecko, an independent browser engine Mozilla builds and maintains itself, rather than inheriting Chromium's release infrastructure the way Edge does. Compressing Firefox's release cycle is therefore a heavier lift for Mozilla's engineering and QA (quality assurance) teams than it was for Microsoft.
Mozilla is calling it an experiment, not a commitment
Mozilla has been careful not to present this as a permanent, settled change. Sylvestre Ledru, Mozilla's director of engineering, described it directly: "This will be an experiment... Work that is not ready should not be rushed, and features can still take the time they need to bake." The company says it will watch how the faster schedule performs in practice and can slow back down if it causes problems.
The stated upside is straightforward: shipping every two weeks instead of every four means finished bug fixes and features reach users roughly twice as fast, and a feature that narrowly misses one release window only waits two weeks for the next one instead of four. Ledru also framed it as making the release process itself more predictable, with fewer last-minute scrambles to hit a single monthly cutoff.
What does not change
Organizations that need stability rather than speed are not forced onto the new cadence. Firefox's Extended Support Release (ESR), the version aimed at enterprises and other environments that prize a locked-down browser over new features, keeps its existing annual release schedule and its own security update stream, unaffected by the switch on the main release line. Firefox 153, the most recent ESR, continues receiving security updates on its own timeline, independent of how fast the regular channel now moves.
For everyday users, the practical experience barely changes at all. Automatic updates keep working exactly as before, just arriving more often and in smaller increments; anyone who prefers to control updates manually can still do so from Firefox's settings.
Where the friction shows up
The group most likely to feel this change is extension and add-on developers, along with anyone doing browser compatibility testing. A faster release cadence means application programming interface (API) changes and deprecations land in shorter, more frequent bursts rather than being batched into a single monthly update. Testing against Firefox now effectively means testing against a moving target twice as often, which pushes teams toward the same kind of automated, continuous compatibility testing that Chrome's cadence already forced on the ecosystem.
Reaction from Firefox's user and developer community has been mixed. Some see the move as sensible parity with the rest of the browser market. Others are wary that Mozilla is following Chrome's playbook more broadly, a sensitivity sharpened by unrelated but concurrent friction over changes to Firefox's extensions platform, and question whether Mozilla's engineering team, smaller than Google's or Microsoft's, can sustain double the release volume without an increase in instability.
What it means in practice
Developers building or maintaining Firefox extensions should tighten their compatibility testing cycle now, before September 1, rather than waiting for the first faster release to cause a surprise. Setting up automated smoke tests against Firefox Beta and Nightly builds, if not already in place, becomes considerably more valuable under a schedule where a breaking change might only be one or two weeks away from a stable release rather than four.
Organizations running Firefox in managed environments do not need to react immediately: staying on ESR insulates them from the faster cadence entirely, at the cost of waiting longer for new features. Everyone else will likely not notice much beyond marginally more frequent update prompts, at least until Mozilla decides, based on how the experiment goes, whether two-week Firefox releases are here to stay.
