{"id":2660,"date":"2019-09-17T16:46:04","date_gmt":"2019-09-17T16:46:04","guid":{"rendered":"https:\/\/blog.mozilla.org\/futurereleases\/?p=2660"},"modified":"2019-09-18T00:04:44","modified_gmt":"2019-09-18T00:04:44","slug":"moving-firefox-to-a-faster-4-week-release-cycle","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/futurereleases\/2019\/09\/17\/moving-firefox-to-a-faster-4-week-release-cycle\/","title":{"rendered":"Moving Firefox to a faster 4-week release cycle"},"content":{"rendered":"

This article is cross-posted from Mozilla Hacks<\/a><\/p>\n

Overview<\/h2>\n

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\u2019ve developed a phased release strategy that includes \u2018pre-release\u2019 channels: Firefox Nightly<\/a>, Beta<\/a>, and Developer Edition<\/a>. With this approach, we can test and stabilize new features before delivering them to the majority of Firefox users via general release.<\/p>\n

Today’s announcement<\/h2>\n

And today we’re excited to announce that we\u2019re 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.<\/p>\n

Starting Q1 2020, we plan to ship a major Firefox release every 4 weeks. Firefox ESR release cadence (Extended Support Release<\/a> 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.<\/p>\n

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.)<\/p>\n

In order to maintain quality and minimize risk in a shortened cycle, we must:<\/p>\n