Simplifying Firefox Release Channels and Improving Developer Edition’s Stability

Streamlining our release process and quickly getting stable new features to users and developers is a priority for Firefox. Taking a close critical look at our release channels, it became clear that Aurora was not meeting our expectations as a first stabilization channel.

Starting on April 18, the Firefox Aurora channel will stop updating, and over the course of the next several months, the Aurora build will be removed from the train release cycle. Developer Edition will be based on the Beta build. Developer Edition users will maintain their Developer Edition themes, tools, and preferences, will keep their existing profile, and should not experience any disruption.

This change benefits developers in several ways:

  • Clearer choices in pre-release channelsNightly for experimental features and Developer Edition/Beta for stability.
  • Higher quality and more stable environment for Developer Edition users.
  • Faster release cycles for platform features. (Benefits everyone!)

Here’s the timeline: On April 18, code for Firefox 54 will move from Aurora to Beta as usual, while Firefox 55 will remain on Nightly for a second cycle in a row (a total of 14 weeks). On the next merge day, June 12, Firefox 55 will move directly from Nightly to Beta. Between April and June, Firefox Aurora on Desktop (54) will continue to receive updates for critical security issues and the Aurora and Developer Edition populations will be migrated to the Beta update channel. On Android, Aurora users will be migrated to Nightly.

Aurora was originally created in 2011 to provide more user feedback after Firefox shifted from version 5 to the high-speed release cycle. Today, in 2017, we have more modern processes underlying our train model, and believe we can deliver feature-rich, stable products without the additional 6-8 week Aurora phase.

A staged rollout mechanism, similar to what we do today with Release, will be used for the first weeks of Beta. Our engineering and release workflow will continue to have additional checks and balances rolled out to ensure we ship a high quality release. A new feature will merge from Nightly to Beta only when it’s deemed ready, based on preestablished criteria determined by our engineering, product and product integrity teams. If features are not ready, they won’t migrate from Nightly to Beta.

New tools and processes will include:

  • Static analyzers integrated as part of the workflow, in order to detect issues during the review phase. They will be able to identify potential defects while minimizing technical debt.
  • Code coverage results will be used to analyze the quality of the test-suite and the risk introduced by the change.
  • The ability to identify potential risks carried by changes before they even land by correlating various data sources (VCS, Bugzilla, etc.) in order to identify functions where a modification is more likely to induce a regression.
  • Monitoring crash rates, QE’s sign offs, telemetry data and new regressions to determine overall Nightly quality and feature readiness to merge to Beta.

For a deeper dive into transition details, please see the Mozilla Release Management blog for in-depth answers to the most common questions about this change.

About Ali Spivak

@alispivak. Ali is the head of Developer Marketing at Mozilla, and has been developing and managing web sites for longer than she cares to admit. She's passionate about keeping the web open and working on things developers love (like MDN).

More articles by Ali Spivak…

About Dave Camp

Dave Camp is Director of Engineering for Firefox at Mozilla.

More articles by Dave Camp…

About Sylvestre Ledru

More articles by Sylvestre Ledru…


13 comments

  1. Dimas

    Which differences will be between Beta and Developer Edition?

    April 17th, 2017 at 09:29

    Reply

    1. Sylvestre

      The theme, some options are enabled in devedition and not beta, different profile, etc

      April 25th, 2017 at 05:14

      Reply

  2. Benjamin Kerensa

    Wow this took long enough :) this was being discussed as an idea years ago

    April 17th, 2017 at 10:08

    Reply

  3. Šime Vidas

    So, say a feature lands in Nightly on August 6 (one day before merge); that feature would then ship in Firefox on September 26. That’s 52 days! I think, this makes Firefox the fastest-shipping major browser.

    April 17th, 2017 at 12:36

    Reply

  4. Charles

    Given that Beta will not accept unsigned add-ons in any form, the “Developer Edition users… should not experience any disruption” is a bit off, no?

    April 17th, 2017 at 19:19

    Reply

    1. Bryan Clark

      Good point, I’ll get the FAQ adjusted to acknowledge that.

      The majority of Developer Edition users won’t experience any disruption. However those developers who rely on unsigned add-ons will need to use Nightly builds until we have finalized the unsigned add-on builds specifically for those developers.

      April 18th, 2017 at 12:33

      Reply

  5. Franz

    Huh, this must be the reason why my Firefox says it’s up-to-date, even though it’s still on version 53. Would be a nicer user experience if the program would inform people about this

    April 18th, 2017 at 06:11

    Reply

    1. Ali Spivak

      Ship date for Firefox 53 / 54 Beta / 55 Nightly is April 19th, so you should see the new updates tomorrow.

      April 18th, 2017 at 07:18

      Reply

  6. Robin Berjon

    This sounds like a really good move.

    Does this mean that that the Developer Edition will start to behave more like the mainline Firefox (eg. stop trying to force you into using a separate profile, drop the angsty dark theme default)?

    Thanks!

    April 20th, 2017 at 06:55

    Reply

    1. M Edward/Ed Borasky (

      Right! If there I have all three on my machine it doesn’t make sense for me to have one profile for the most and the least stable and a second profile for the one in the middle! Either have three profiles, optionally Firefox-synced, or one.

      Nor does it make sense to have the “marketing” distinction of Developer Edition when you can customize any of the three to have exactly the UI you want to the extent that the features you want are available.

      I’ve pretty much stopped running Nightly on Linux because it shares a profile with stable. I am starting up a project that has a huge front-end component and I’ve got till the end of June to get it built. If I could run Nightly with a special profile and the other two with the “stable” profile I’d do that.

      April 20th, 2017 at 13:25

      Reply

      1. Dan Callahan

        You can run Nightly with a special profile, and the others with a stable profile. That’s what I do. You just have to use Profiles. It’s what I do. :)

        You can specific a profile at launch by using the -P command line argument. I have Nightly set to launch with -P Work and Beta with -P Personal, for example.

        April 21st, 2017 at 12:52

        Reply

  7. clem

    bad news for Aurora, I use it since a while (won via devloper version), it’s works perfectly.

    April 22nd, 2017 at 03:13

    Reply

  8. Oriol

    Yesterday I read a post from 2014 where dbaron proposed more or less the same change (https://dbaron.org/log/20141106-release-cycles), and today I see this article. What a coincidence.

    April 24th, 2017 at 10:38

    Reply

Post Your Comment