Mozilla will begin an experiment in September 2026 to shorten the interval between major releases of Firefox Desktop and Android from the current four weeks to two weeks. The first release affected, Firefox 155, will move up two weeks from its originally scheduled date of September 15 to September 1. This marks a milestone that halves the four-week cycle that has been in place since 2020.
However, this is not a plan to halve the development period itself. Mozilla has explicitly stated that it will not rush out unfinished features and will still take the necessary time for verification. What's changing is the number of "trains" carrying ready-to-ship changes to the stable channel. Mozilla will measure whether quality can be maintained while increasing release opportunities, and will adjust the schedule based on the results.
Biweekly Starting with Firefox 155 on September 1
Mozilla's public release calendar already reflects the dates before and after the transition. There is a 28-day gap between Firefox 153 and 154, but only 14 days between 154 and 155. After that, stable releases are planned for every other Tuesday, at least through Firefox 160.
| Version | Scheduled Stable Release Date | Interval from Previous Version |
|---|---|---|
| Firefox 153 | July 21, 2026 | – |
| Firefox 154 | August 18, 2026 | 28 days |
| Firefox 155 | September 1, 2026 | 14 days |
| Firefox 156 | September 15, 2026 | 14 days |
| Firefox 157 | September 29, 2026 | 14 days |
| Firefox 158 | October 13, 2026 | 14 days |
Firefox 155 was originally scheduled for September 15. This change, therefore, is not about incrementing future version numbers—it's about moving forward a release date that was already scheduled. Sylvestre Ledru, Mozilla's release management lead, describes this initiative as an "experiment." The goals are to increase opportunities to deliver ready-to-ship changes to users, make the release schedule more predictable, and reduce pressure for "uplifts"—fixes pushed ahead of schedule outside the normal process.
The explicitly named targets are the Desktop and Android versions. The iOS version is not included in the announcement. Also unpublished is how long the two-week cycle will continue or what metrics will be used to decide whether to continue it. Firefox 155 is not the first instance of a permanent transition, but rather the starting point for gathering operational data.
Weekly Minor Updates and Biweekly Major Updates
Firefox already had a weekly update mechanism in place prior to this experiment. Starting with Firefox 151, Mozilla incorporated weekly "dot releases" into the Desktop and Android versions. This is an operational approach that creates a weekly opportunity to deliver approved fixes and uplifts in the weeks following a major release.
Dot releases are implemented by the release management team when there are ready-to-ship changes. If none are needed, they can be skipped. On the other hand, the biweekly schedule starting with Firefox 155 increases the regular cadence of major releases that advance code from Nightly to Beta to stable. Since waiting for the next version becomes shorter than exceptionally porting a fix to the current version, this makes it easier to reduce the need for uplift decisions.
The mechanism for gradually expanding release scope also remains in place. Starting with Firefox 152, Mozilla changed its approach to roll out major releases to 25% of stable users on day one, maintain that state for two days, and then expand to 100% if no issues arise. Even with a shortened update cycle, the design still ensures time to verify early-stage usage and stability.
Splitting four weeks' worth of changes into two releases means the average amount of change per release will be smaller. However, the completion dates for individual features won't necessarily align, and some larger features may span multiple cycles. What users receive isn't "a Firefox built in half the time"—it's a Firefox with more opportunities to ship completed changes.
Edge, Firefox, and Chrome Converge Within 12 Days
In the fall of 2026, the stable releases of Microsoft Edge, Firefox, and Google Chrome will successively transition to a two-week cycle. Edge begins its new schedule on August 27, Firefox on September 1, and Chrome on September 8. The first transitions are concentrated within a 12-day window, with the release schedules of all three products changing at nearly the same time.
| Browser | First Biweekly Cycle | Long-Term Support Channel |
|---|---|---|
| Microsoft Edge | Edge 152, August 27 | Extended Stable remains at 8 weeks |
| Firefox | Firefox 155, September 1 | ESR feature updates remain annual |
| Google Chrome | Chrome 153, September 8 | Extended Stable remains at 8 weeks |
Google will release Beta and Stable every two weeks starting with Chrome 153. This applies to Desktop, Android, and iOS, while Dev and Canary remain unchanged. Extended Stable for enterprise use will also maintain its 8-week cycle. Microsoft will similarly make Stable biweekly starting with Edge 152, but Extended Stable will receive a major release once every four cycles, maintaining an 8-week interval.
What's common across all three companies is the philosophy of increasing the number of consumer-facing stable trains while preserving a slower track for managed devices. The difference lies in scope. Chrome has explicitly named all platforms, including iOS, whereas Firefox's announcement is limited to Desktop and Android. Regarding Firefox ESR as well, the body of this announcement does not describe any operational changes.
Enterprises Should Read ESR and the Public Calendar Separately
Administrators who deploy Firefox within organizations need to view the "frequency" and "content" of updates separately. The regular release channel incorporates new features, UI changes, and privacy/security behavior changes with every major version. As a result, opportunities to verify compatibility with internal web apps and extensions will also increase from every four weeks to every two weeks. The value of the Beta pre-validation group becomes even greater than before.
ESR follows a different design. According to Mozilla's administrator documentation, a new ESR baseline version is released once a year, with point releases in between primarily carrying security updates. UI and feature changes are not introduced until the next annual ESR. This means organizations that prioritize a stable interface and behavior don't need to repeat feature verification at the same frequency as the regular channel.
On the other hand, a transitional state is visible in the official documentation immediately following the change. As of July 10, the administrator-facing page still describes the regular channel as "every four weeks." Yet the public calendar lists ESR 153.2 on September 1—the same date as Firefox 155—followed by 153.3 on September 15 and 153.4 on September 29. At least under the current schedule, ESR feature delivery remains annual, while security-focused point release opportunities are placed every two weeks.
This discrepancy indicates that administrative documentation will need to be updated in the period between the announcement and the transition. Under the current documentation, old and new ESR versions are supported in parallel for three release cycles, or a minimum of 12 weeks. Whether this minimum 12-week period will be maintained under the two-week cycle, or whether the cycle count will be recalculated, is not addressed in this announcement. This will need to await further updates from Mozilla, along with point release distribution policies and enterprise verification procedures.
Mozilla says it will monitor the experiment and make adjustments as necessary. Will the biweekly schedule hold steady beyond Firefox 155, reducing exceptional uplifts without compromising stability? The next several releases starting in September will provide the data needed to make that determination.