The Firefox release process

< Release Management

Contents

Channels/Repositories

  • Firefox Release/mozilla-release — The official release of Firefox.
  • Firefox Beta/mozilla-beta — Testing the next version of Firefox before it becomes the official release. Firefox Beta channel is also built from the Beta branch.
  • Firefox Nightly/mozilla-central — Nightly releases that contains experimental features (covered regularly on Twitter from @FirefoxNightly).
  • Firefox ESR/mozilla-esr78 — Official Desktop releases for Organizations. Check the wiki for detailed information.

See the Tree Rules before pushing patch into any repository.

Maintrepositories.png

Download Links for Firefox for Desktop

Get the latest version of Firefox for Windows, macOS or Linux across all channels and check the Release notes for new features, enhancements or changes.

Download Links for Firefox for Android

You can get the latest release, beta and Nightly versions of Firefox for Android on the Google Play Store.

Release timeline

The standard release interval of Firefox is four weeks (not counting urgent patch updates), meaning that every four weeks there will be a new version of Firefox Release. The release interval is sometimes lengthened due to holidays.

From mozilla-central to mozilla-release

  • Firefox Nightly contains all the changes landed on mozilla-central. Regular Nightly releases occur about every 12 hours, with additional releases generated when a Nightly release has a major problem.
  • Every 4 weeks, we merge the code from mozilla-central to our mozilla-beta branch. The mozilla-beta branch should now only get patches aimed at stabilizing the release. Any patch on mozilla-central that we want backported to our mozilla-beta branch should follow the approval rules for uplifts.
  • Firefox Beta is released three times a week for Desktop, leaving us with 9 betas every cycle unless we have chemspills leading to additional betas. Firefox Beta 1 and 2 are shipped to a subset of our Beta population. The full Beta population gets updated starting with beta 3 only.
  • At the end of the Beta cycle, a final build is validated by our QA and tagged for release into the mozilla-release branch.

Android specificities

  • Firefox for Android Nightly builds are created at the same time as Desktop (2x daily), but typically only one is pushed to Google Play daily due to app review limitations.
  • Firefox for Android Beta builds are created at the same time and frequency as their Desktop counterparts and follow the same rollout strategy.
  • Firefox for Android Release Candidate builds are pushed to Production at 5% rollout during RC week to get early feedback. The rollout is bumped to 25% on the official release date to match Desktop.

Release day activities/checklist can be found on the Release Day wiki page.

Our release schedule is meant to be flexible and we may occasionally modify the length of a cycle to be shorter or longer than the 4-5 week cycle mentioned. Check the Release Calendar to stay updated with the upcoming branch dates.

Nightly soft code freeze

The last few days of the nightly cycle, before merge day (when mozilla-central is merged into the mozilla-beta repository and a new release cycle starts), is a nightly soft code freeze, meaning that developers should not land on mozilla-central code that is deemed risky for the stability and general quality of Firefox and that features that are controlled by a pref and were not activated during the nightly cycle should not be activated during this week.

If you land code that introduces new crashers or lowers the overall quality of Firefox during that period, we will back it out instead of waiting for a follow-up fix.

All about Flags

The Process

1) If you think a bug needs to be addressed in a release:

  • Set the tracking-Firefox XX: ? nomination on a bug for with helpful justification and keeping these guidelines in mind
  • Mark the corresponding status flag as affected if the patch is still being worked on
  • Once the patch is ready set the approval flag appropriately depending on which branches are affected

2) Members of Release Management go through all the bugs nominated for tracking and if in agreement that this bug needs to be investigated in that release we will go ahead and set tracking-Firefox XX: +. Once we track a bug for a particular release we will make sure to follow-up on the progress or help with any road blockers till you have a patch nominated for approval.

Note: Bugs denied for tracking-Firefox XX are still important. It merely means based on the information we have now,we do not feel the bug would prevent us from shipping a release. If new information comes to light, you need help getting more data before you can make the case for us to track, or you disagree with our assessment feel free to renominate again with additional justification.

3) Once you nominated a patch with approval-mozilla-beta/release: ? we will evaluate the information given in the attachment request we may either approve/deny/request more information. Once you get an approval , i.e approval-mozilla-beta/release: +, sheriffs or release managers will land it on the corresponding branch and mark status-Firefox XX flag to fixed, making sure Treeherder is green.

Note: In the case that a tracked bug is resolved as a duplicate bug, it is best practice for the release management team to remove the tracking flag from the duplicate bug and add it to the active linked bug.


Also see:

Security Bug Approval Process

  • In case you are working on a security bug please make sure to read the approval process before checking in the patch.

Crashes

  • Type about:crashes in Firefox to get links to your crashes.
  • You can obtain crash-data across any channel for all Firefox products by customizing the needed reports from the Socorro dashboard.
  • If the information on the Socorro dashboard does not suffice for the crasher you are investigating and you need access to raw data, additional crash-dumps or other data related to the crash, you can file a Bug and forward the request to the Socorro team as a start to help you.

ESR

Queries

Following are the queries that Release management goes through almost day-day to make sure we are tracking the right blockers,getting them fixed and make sure these bugs get fixed (heard of nag emails yet:) ? ) for a particular Firefox release.

  • Bugs tracking for release
    • Bugs tracking Firefox Beta 132

Nag Emails

  • To ensure that these tracking Bugs get the needed attention and keeping in mind the deadlines in case you forget Release Management sends you friendly nag emails for these blocker email's to make sure these get the needed priority and attention as they are are considered potential blockers for release.
  • If you are working on a tracked bug you may have seen emails with Subject similar to: RelMan Attention Needed: Monday May 20 -- Daily Release Tracking Alert for bugs that are actively not being worked on or if any of the bugs may have a needsinfo on you and is blocking progress.
  • This has also been very helpful to avoid any communication gap between Release drivers and developers and help us be on the same page and setting the right expectation about a tracked bugs progress and resolution.

Release notes for Desktop/Android

Release Notes page describes the release notes process, the relnote-firefox tracking flag, styling guide and other relevant details.

Please check the Release_Management/Release_Notes_Process#What.27s_New.2FKnown_Issues_Section_Candidates Release Notes documentation for the process we currently have to construct release notes. Below are the links to all the existing release notes across all channels.

See FAQ

Getting help

  • Matrix
  • Mailing Lists for any release-related issue
    • release-mgmt@mozilla.com
    • release-drivers@mozilla.org
    • enterprise@mozilla.org (enterprise related issues)
  • Google groups
    • mozilla.dev.platform
    • mozilla.dev.planning
    • mozilla.announce
  • Be part of the Channel Meetings if you are interested in day-day updates for desktop/mobile releases