«  Firefox 168  »
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 firefox-main to the beta branch, we bump the nightly version number on firefox-main 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.

QA signs off on new features in Nightly by sharing individual test reports with their quality assessment and reasoning.

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.

This is the day in the release cycle when we merge firefox-main into the beta branch. This is the end of the development cycle for Firefox 168 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.

Deadline for security bugs uplift requests (sec-approval+ on Bugzilla).
ESR releases go to build on this day, before the last beta and the Release Candidate. Patches for security bugs affecting ESR branches must therefore be ready by this deadline.

Last beta of the cycle and thus the end of beta uplifts. Build starts at 13:00 UTC.
After beta 5, we merge the beta branch to the release branch and close beta until the next merge day. We then build our Release Candidate from release.

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.

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 168 ships at 13: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.