«  Firefox 153  »
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.

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.

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 assess build readiness for shipping to Beta by running a set of Regression test cases and shares 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 153 and the beginning of our Beta stabilization cycle.

Rolled out to 50% of our beta population. Some experimental features are still activated to watch their behavior on a wider population. These experimental features will be deactivated mid-cycle.

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 and will be translated before RC week.

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

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

On a regular 4 weeks beta cycle, Beta 5 is the last beta with experimental features still activated. Build starts at 13:00 UTC. Stabilization work via uplifts.

Build starts at 13:00 UTC. Stabilization work via uplifts. Experimental features are no longer activated at compile time.

New content on support.mozilla.org team is finalized, uploaded to the server and provided to our localization teams internationally.

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

A week before the final sign-off, QA shares preliminary test reports for each feature riding the train. This pre-release sign-off can be Green, Yellow or Red.

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

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

Build starts at 13:00 UTC. Stabilization work via uplifts.
Last security bugs uplifts for this release (sec-approval+ on Bugzilla).

Extra beta usually due to a longer beta cycle. Build starts at 13:00 UTC. Stabilization work via uplifts.

Extra beta usually due to a longer beta cycle. Build starts at 13:00 UTC. Stabilization work via uplifts.

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.

Extra beta usually due to a longer beta cycle. Build starts at 13:00 UTC. Stabilization work via uplifts.

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.

Our Release Candidate is built and available for testing.

We ship Firefox 153 at 14:00 UTC (6AM PST) at 25% rollout.

One week after the release, we evaluate shipping an Android dot release to address identified issues. We can also enable new features on a on a case by case basis if they are suitable for uplift. The decision on shipping or not this dot release for Android is on the release management team.

Two weeks after the release, we ship a desktop and/or an Android dot release to address identified quality issues with safe fixes ready. We can also enable new features on a on a case by case basis if they are suitable for uplift. We may have to ship other dot releases before that date. If this is the case and post-release quality issues are already fixed and shipped, the decision on shipping or not the planned dot release is on the release management team.