«  Firefox 160  »
Go to Release channel

QA has been informed via a Jira ticket (Functional, Nimbus/Remote delivery or Embedded QA) about features needing manual testing — more on how to file a Jira ticket here. Test Plans and Cases also require the technical documentation, which should be attached to the ticket.

Accessibility engineering review has been requested (using the a11y-review flag on Bugzilla) for new (or significantly redesigned) UI that requires assessment to determine whether it is accessible to people with disabilities.

The first day of the cycle is Merge Day. After merging mozilla-central to mozilla-beta, we bump the nightly version number on mozilla-central and a new development cycle starts for Firefox. A new Firefox Nightly is shipped every 12 hours.

Features with a QA request are ready for testing to assess feature quality and provide a formal test report by the end of Week 2 of the nightly cycle.

The QA team appreciates an earlier sign-off from the project teams. The approval milestone will be the final deadline for any feature Test Plan sign-offs. No feedback/sign-off on QAs Feature Test Plan could result in misalignment on testing scope, incomplete test coverage and invalid bugs.

Final strings are handed off to Engineering to ensure they are landed before localization begins.

In order to ensure that our localizers have adequate time to translate strings, please make sure that all string changes have landed by end of day.

A draft document was created and shared internally with stakeholders to prepare our final release notes for general availability. This document initially contains a copy of our public beta release notes shipping the week after and will be enriched during the beta cycle with media and final copy.

QA signs off on the Nightly build, assessing its readiness for shipping to Beta by running a set of regression test cases and sharing a test report.

This is the day in the release cycle when we merge mozilla-central into mozilla-beta. This is the end of the development cycle for Firefox 160 and the beginning of our Beta stabilization cycle.

First beta of the cycle, rolled out to our beta population. Build starts at 13:00 UTC. Stabilization work via uplifts.

First automated beta of the cycle. It is rolled out to 100% of our beta population. Build starts at 13:00 UTC.
Stabilization work via uplifts.

User affecting changes were identified and provided to the support.mozilla.org team. The support content for this release can now be created before release day.

Build starts at 13:00 UTC. Stabilization work via uplifts.

Build starts at 13:00 UTC. Stabilization work via uplifts.

Last beta of the cycle and thus the end of beta uplifts. This is also the deadline for security bugs uplift requests (sec-approval+ on Bugzilla). Build starts at 13:00 UTC.

All release notes for Firefox were added to the draft document or communicated directly with the release manager. Illustrations such as screenshots and videos were provided. Final Release release notes are created by the release manager on firefox.com.

We merge our mozilla-beta repository to mozilla-release and close mozilla-beta until the next merge day. We then build our Release Candidate from mozilla-release. This is the build we intend to ship a week later unless we need to build another Release Candidate to fix a major quality or business critical issue.

Firefox 160 ships at 14:00 UTC (6 AM PT) with an initial 25% rollout.

Scheduled for one week after launch, this Desktop and/or Android release targets critical quality fixes and selective feature uplifts. The deadline for uplift requests is EOD on the Friday prior to go-live. Should emergency dot releases ship earlier and resolve pending issues, the Release Management team will determine if this scheduled milestone remains necessary.