Mozilla is cutting Firefox's major release cadence in half, from four weeks to two, starting with Firefox 155 on September 1, 2026. Sylvestre Ledru, a Director at Mozilla, confirmed the change in a message to the Firefox development team. Firefox 154, due August 18, is the last update on the monthly schedule. Mozilla is explicit that this is an experiment rather than a commitment, and the framing matters: this is the last of the three major browser vendors to make a move that Chrome started in March and Edge ships in August.
- Firefox 155 arrives September 1, 2026 instead of September 15, and every major Desktop and Android release after that lands on a two-week rhythm.
- Firefox 154 on August 18 is the final four-week release. iOS is not included in the announcement.
- Mozilla frames it as an experiment and has not published how long it runs or what metrics decide whether it sticks.
- The stated goal is shipping ready work sooner and reducing uplift pressure, not making developers move faster. A feature that misses a window waits two weeks, not a month.
What exactly is changing?
Mozilla currently ships major Firefox Desktop and Android updates every four weeks. Under the new schedule, those arrive every two weeks starting in September 2026. Firefox 154 lands August 18 as the last monthly release. Firefox 155, which was scheduled for September 15, moves to September 1. The Firefox Release Calendar has already been updated. iOS is not named in the announcement, which makes sense given Firefox on iOS is a WebKit wrapper and follows a different constraint set entirely.
RelatedThe Anti-AI Browser Backlash Is Fueling DuckDuckGo's Surge
For users, essentially nothing changes operationally. Updates arrive the same way, through Firefox's automatic updater or your Linux distribution's repositories. The visible difference is that version numbers climb twice as fast, which means the Firefox 200 jokes are now roughly two years out rather than four.
Why would you halve a release cycle?
The reasoning Mozilla gives is about the shape of the release train, not the speed of the engineers, and this is the part most coverage skips. Mozilla explicitly says the two-week cadence does not require development to move twice as fast, that features which are not ready should not be rushed, and that developers still get adequate time for testing and stabilization.
So what does it buy? Two things. First, work that is ready ships sooner. Under a four-week cycle, a feature that lands the day after the merge window closes sits for a month. That is a month of finished code doing nothing. Halve the cycle and you halve the average dead time.
Second, and more interesting to anyone who has worked on a release train: it reduces uplift pressure. An uplift is the request to backport a change into a branch that has already been cut, and every one of them is a risk decision made under time pressure. The pressure to uplift is a direct function of how long the next train is. When the wait is a month, everything feels urgent enough to justify the risk. When the wait is two weeks, the honest answer is usually "it can wait," and the branch stays stable. Shorter cycles make the safe choice the easy choice.
Is Firefox following or leading?
Following, clearly, and the sequencing is worth being precise about because it inverts the usual assumption. Chrome started this: Google first moved to a bi-weekly cadence in March 2026. Microsoft followed for Edge. But in actual shipping order, Edge goes first on August 27, Firefox 155 lands September 1, and Chrome, despite announcing first, rolls out last on September 8.
That ordering says something about how browser release engineering actually works. Announcing a cadence change is cheap. Rewiring the CI, the QA gates, the localization pipeline and the enterprise support commitments around it is not, and Chrome having the longest gap between announcement and rollout is the tell. Firefox getting there a week ahead of Chrome, on a fraction of the headcount, is a genuinely respectable piece of release engineering.
| Browser | Firefox | Chrome | Edge |
|---|---|---|---|
| Announced | July 2026 | March 2026 | After Chrome |
| Two-week cadence starts | September 1 | September 8 | August 27 |
| First release on new cadence | Firefox 155 | Not specified | Not specified |
| Platforms | Desktop + Android | Desktop + mobile | Desktop |
| iOS included | No | n/a | n/a |
| Framed as | An experiment | A change | A change |
| Exit criteria published | No | n/a | n/a |
Who does this actually affect?
Regular users: nobody. The updater does its job and the version number moves faster.
Enterprise administrators: more than they would like. Organizations that test and certify each browser version against internal applications now have half as long between releases to do the same work. Firefox's Extended Support Release exists precisely for this constituency, and the ESR channel is unaffected, so the practical answer for a locked-down fleet is the same as it always was. But teams tracking the rapid channel are looking at double the certification load.
RelatedWeb Bot Auth: The IETF Standard to Verify AI Agents
Extension developers: a real cost. Every release is a potential compatibility surface, and the testing matrix just doubled. That is not catastrophic, since most WebExtension APIs are stable across releases, but the tail of extensions that poke at internals will feel it.
Web developers: mildly good news. Standards implementations reach stable users faster, and the gap between "shipped in Nightly" and "safe to use" compresses. When all three engines are on two-week trains, feature availability converges faster across the board, which is quietly the biggest win here.
- Whether the experiment gets exit criteria. Mozilla has not said what success looks like or how long the trial runs. Without published metrics, "experiment" is indistinguishable from "change we might reverse if people complain."
- Regression rate. The obvious failure mode is more releases meaning less stabilization per release. Watch whether Firefox's dot-release frequency climbs after September.
- ESR pressure. If enterprises find the rapid channel unmanageable at two weeks, ESR adoption rises, and that fragments the field further.
- Interop velocity. With Chrome, Edge and Firefox all on two weeks by mid-September, watch whether Interop 2026 features land across engines noticeably faster.
Our take
This is a good change made for the right reason, and the reason is the one Mozilla stated most quietly: reducing uplift pressure. Anyone who has worked a release train knows that the length of the cycle is what turns reasonable engineers into people arguing that their patch absolutely must go into the branch that was cut yesterday. Shortening the wait removes the incentive to take that risk. That is a stability improvement dressed up as a velocity improvement, and it is the sort of thing that only shows up in the numbers a year later.
The weak spot is the word "experiment." Mozilla has not published how long the trial runs or what would make it stop, which makes the label do no work. An experiment without a hypothesis or a stopping rule is just a change with a hedge attached. If the regression rate climbs and the dot-releases pile up, Mozilla will need a number to point at when it decides. Better to publish that number now than to argue about it in December.
- OfficialFirefox Release Calendar the authoritative schedule, already updated for the new cadence
- ReferenceMozilla Wiki: Release Management how the train, uplifts and channels actually work
Original analysis by GenZTech. Cadence change confirmed by Mozilla's Sylvestre Ledru to the Firefox development team; dates per the Firefox Release Calendar.