Moving Firefox to a faster 4-week release cycle

Editor’s Note: Wednesday, 10:40am PT. We’ve updated this post with the following correction: The SeaMonkey Project consumes Firefox releases, not SpiderMonkey, which is Firefox’s JavaScript engine. Thanks to an astute reader for noticing.


We typically ship a major Firefox browser (Desktop and Android) release every 6 to 8 weeks. Building and releasing a browser is complicated and involves many players. To optimize the process, and make it more reliable for all users, over the years we’ve developed a phased release strategy that includes ‘pre-release’ channels: Firefox Nightly, Beta, and Developer Edition. With this approach, we can test and stabilize new features before delivering them to the majority of Firefox users via general release.

Today’s announcement

And today we’re excited to announce that we’re moving to a four-week release cycle! We’re adjusting our cadence to increase our agility, and bring you new features more quickly. In recent quarters, we’ve had many requests to take features to market sooner. Feature teams are increasingly working in sprints that align better with shorter release cycles. Considering these factors, it is time we changed our release cadence.

Starting Q1 2020, we plan to ship a major Firefox release every 4 weeks. Firefox ESR release cadence (Extended Support Release for the enterprise) will remain the same. In the years to come, we anticipate a major ESR release every 12 months with 3 months support overlap between new ESR and end-of-life of previous ESR. The next two major ESR releases will be ~June 2020 and ~June 2021.

Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market requirements. With four-week cycles, we can be more agile and ship features faster, while applying the same rigor and due diligence needed for a high-quality and stable release. Also, we put new features and implementation of new Web APIs into the hands of developers more quickly. (This is what we’ve been doing recently with CSS spec implementations and updates, for instance.)

In order to maintain quality and minimize risk in a shortened cycle, we must:

  • Ensure Firefox engineering productivity is not negatively impacted.
  • Speed up the regression feedback loop from rollout to detection to resolution.
  • Be able to control feature rollout based on release readiness.
  • Ensure adequate testing of larger features that span multiple release cycles.
  • Have clear, consistent mitigation and decision processes.

Firefox rollouts and feature experiments

Given a shorter Beta cycle, support for our pre-release channel users is essential, including developers using Firefox Beta or Developer Edition. We intend to roll out fixes to them as quickly as possible. Today, we produce two Beta builds per week. Going forward, we will move to more frequent Beta builds, similar to what we have today in Firefox Nightly.

Staged rollouts of features will be a continued best practice. This approach helps minimize unexpected (quality, stability or performance) disruptions to our release end-users. For instance, if a feature is deemed high-risk, we will plan for slow rollout to end-users and turn the feature off dynamically if needed.

We will continue to foster a culture of feature experimentation and A/B testing before rollout to release. Currently, the duration of experiments is not tied to a release cycle length and therefore not impacted by this change. In fact, experiment length is predominantly a factor of time needed for user enrollment, time to trigger the study or experiment and collect the necessary data, followed by data analysis needed to make a go/no-go decision.

Despite the shorter release cycles, we will do our best to localize all new strings in all locales supported by Firefox. We value our end-users from all across the globe. And we will continue to delight you with localized versions of Firefox.

Firefox release schedule 2019 – 2020

Firefox engineering will deploy this change gradually, starting with Firefox 71. We aim to achieve 4-week release cadence by Q1 2020. The table below lists Firefox versions and planned launch dates. Note: These are subject to change due to business reasons.

a table showing the release dates for Firefox GA and pre-release channels, 2019-2020

Process and product quality metrics

As we slowly reduce our release cycle length, from 7 weeks down to 6, 5, 4 weeks, we will monitor closely. We’ll watch aspects like release scope change; developer productivity impact (tree closure, build failures); beta churn (uplifts, new regressions); and overall release stabilization and quality (stability, performance, carryover regressions). Our main goal is to identify bottlenecks that prevent us from being more agile in our release cadence. Should our metrics highlight an unexpected trend, we will put in place appropriate mitigations.

Finally, projects that consume Firefox mainline or ESR releases, such as SeaMonkey and Tor will have to do more frequent releases if they wish to stay current with Firefox releases. These Firefox releases will have fewer changes each so they should be correspondingly easier to integrate. The 4-week releases of Firefox will be the most stable, fastest, and best quality builds.

In closing, we hope you’ll enjoy the new faster cadence of Firefox releases. You can always refer to for the latest release dates and other information. Got questions? Please send email to

About Ritu Kothari

Ritu leads the Firefox release management team.

More articles by Ritu Kothari…

About Yan Or

Yan leads the Product Integrity team for Firefox.

More articles by Yan Or…


  1. Matthew Beale

    As part of the change in schedule many developer should probably take a moment to reconsider their support policies (“last two versions” would now require an update of FF in the past 4 weeks in the worst case).

    Can you share any numbers about what the distribution of FF versions is in the wild, about how quickly users usually upgrade, and about if you expect any change as a part of this tweak to the FF release policy?

    September 17th, 2019 at 09:48

    1. Ritu Kothari

      Thank you for your feedback. I don’t have the user data to share. However, we plan to closely monitor usage numbers and the impact of this change. If you are an ESR user, this change will not impact the 3-month overlap between end-of-life of the previous ESR and next major ESR release. Hope this helps!

      September 17th, 2019 at 15:48

  2. Cypherous

    Now if only you could bring Quantum up to feature parity with FF 56


    September 17th, 2019 at 10:34

  3. Patricia

    > Finally, projects that consume Firefox mainline or ESR releases, such as SpiderMonkey and Tor, now have more frequent releases to choose from.

    Currently they have the latest ESR or the latest stable release. An older version would be bad in terms of security. Or do you mean that TOR can take beta version more frequently for development?

    September 17th, 2019 at 11:46

    1. Ritu Kothari

      Thanks for your feedback. If downstream projects like Tor wish to stay current with Firefox releases then yes, they will have to do more frequent releases

      September 17th, 2019 at 16:16

  4. askingforafriend

    Does it include mobile browsers as well?

    September 18th, 2019 at 02:14

    1. Ritu Kothari

      This includes Firefox for Android.

      September 18th, 2019 at 08:01

  5. gwen

    I just loved reading your articles.The best thing which I really like about your articles is, you covers each and every thing in your articles which makes your article more helpful.I have seen people love to read those articles more which are easy to understand and can help a lot. And you always write such kind of articles.
    Thanks for sharing this informative article and keep doing the good work.

    September 18th, 2019 at 07:13

  6. Thomas Brown

    For anything other than the most critical security patches, these frequent releases are an inconvenience to ordinary users, and cause IT admins disruption to their user communities. The push for frequent releases will inevitably lead to shoddy work when a developer had the freedom to simply fix a bug in the next release. You will simply wind up with end-users disabling updates altogether rather than accepting a quarterly patch.

    September 18th, 2019 at 08:27

    1. Ritu Kothari

      Thanks for your feedback. We are not pushing developers to fix or implement features in 4 weeks, they have the same time as they did before, we just have more windows of opportunity to release those changes now.

      September 18th, 2019 at 10:54

  7. branko

    Hello, considering ever faster update cycles has there been improvement or is there a plan to upgrade update process?

    In sense, to have an option for browser to autoupdate on each close or opening of. Or considering now multiprocess execution dream would be to update browser seamlessly as it is runnig – but then again I assume that hotswapping takess considerably more effort to get right an is much more error prone.

    Also, thank you, all of you, for you continued work, time, patience and effort! It is very much appreciated.

    September 19th, 2019 at 07:37

  8. Warren Lee

    What about us people that just like using FireFox because it is great ! I’ve had a stroke and really like using it because it is easy and convenient. I don’t understand all this new stuff you’re doing, so will I have to use a new browser? Please help me understand what’s going on. I do not want to stop using FireFox.

    September 19th, 2019 at 10:48

    1. Ritu Kothari

      Please continue using Firefox. You should not notice any change.

      September 25th, 2019 at 15:10

  9. YCSMD

    Thanks for sharing this informative article and keep doing the good work.

    September 20th, 2019 at 03:16

  10. Deepak Soni

    This is really nice to see that Mozilla is picking up the 4 weeks release cycle and making their release plan more agile. wishing luck!! for the further Mozilla releases!! Also, I am really curious to know about the two different pipelines you people have one is for experimental and another is main line for feature development. would like to connect with you and discuss further, If time permits :).
    Thanks for sharing information..Keep it up the great work.

    September 20th, 2019 at 22:28

  11. Hogren

    Good luck for this new technical challenge !

    September 25th, 2019 at 05:17

Comments are closed for this article.