The Firefox release process

From MozillaWiki
Jump to: navigation, search

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-esr52 — 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

Firefox is released at intervals of six to eight weeks (not counting urgent patch updates), meaning that every six to eight weeks there will be a new version of Firefox Release.

From mozilla-central to mozilla-release

  • Firefox Nightly is released every 12 hours with all the changes landed on mozilla-central.
  • Every 6 to 8 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.
  • Beta 1 and Beta 2 are built from this beta branch and used to build and ship Firefox Developer Edition as a stabilization step before shipping Firefox Beta to our much wider Beta audience.
  • Starting with Beta 3, Firefox Beta is released twice a week for Desktop, leaving us with 12 to 16 betas every cycle unless we have chemspills leading to additional betas. Firefox Beta 3 is shipped to a subset of our Beta population. The full Beta population gets updated starting with beta 4 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 Nightly is released every 24 hours
  • Starting with Beta 3, Firefox Beta is released once a week for Android, leaving us with 6 to 9 betas every cycle.

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 6-8 week cycle mentioned. Check the [[Release_Management/Calendar|Release Calendar] to stay updated with the upcoming branch dates.


Nightly soft code freeze

The last week of the nightly cycle, before merge day (when mozilla-central is merged into the mozilla-beta repository and a new release cycle starts), is nightly soft code freeze week, 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 lower the overall quality of Firefox this week, we will back it out instead of waiting for a follow-up fix.


All about Flags

Status.png

tracking-firefoxXX

A flag which show whether a bug is being investigated for possible resolution in the Firefox XX release. Bugs marked tracking-Firefox XX are bugs that must be resolved one way or another before a particular release ships. Release drivers will track and shepherd the bug until it is determined the bug no longer impacts the release.

tracking-firefoxXX
 ? This bug has been nominated to block Firefox XX
- Drivers have determined this bug will not block Firefox XX
+ Drivers have determined this bug will block the Firefox XX release or may be tracked after the Firefox XX release

Refer to these guidelines on setting the tracking flag

status-firefoxXX

A flag which represents the status of the bug with respect to Firefox XX.

status-firefoxXX
--- We don't know whether Firefox XX is affected
 ? We don't know whether Firefox XX is affected, but we want to find out
unaffected This bug does not affect Firefox XX
affected This bug affects Firefox XX
fix-optional This bug affects Firefox XX, we would take a fix but don't consider it as release blocking
fixed This bug is fixed in Firefox XX
verified This bug is fixed and verified in Firefox XX
checkin-pending A patch for this bug was written and we are waiting for the code to be committed to the branch
disabled This feature is disabled in Firefox XX
verified disabled Disabling the feature is verified in Firefox XX
wontfix A fix for this bug will not be accepted in Firefox XX
  • Approval Flags: Set on the attachment of a bug

All patches landing on mozilla-beta/release/esr branches must have these nominated by setting a  ? flag.
Please make sure to fill in the populated list of questions [Approval Request Comment] that come up on the attachment. This helps Release Management understand the user impact & the risk/reward analysis before we grant or deny approval. If this form is left incomplete it will be sent back to you for completion.

ApprovalRequest.png

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: +, please go ahead with landing on the corresponding branch and mark status-Firefox XX flag to fixed, making sure Treeherder is green.


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 61

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

  • IRC
    • irc.mozilla.org
    • Some channels:#introduction, #release-drivers, #developers, #planning, #mobile
    • More info on irc
  • Mailing Lists for any release-related issue
    • release-mgmt@mozilla.com
    • release-drivers@mozilla.com
    • 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