«  Firefox 150  »
Go to Release channel

QA has been informed (via a Jira ticket) about features that require manual testing during the nightly and/or beta cycle.
Feature technical documentation is also required to draft Test Plans and Test Cases.

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.

We are nearing the end of the nightly cycle. Don't land new untested features. Risky changes should be avoided after 8:00 AM UTC until after the nightly version bump on Merge Day.

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 150 and the beginning of our Beta stabilization cycle.

Built manually just after the merge. It ships on Tuesday. Uplift requests are open.

Rolled out to 25% 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 50% of our beta population. Build starts at 13:00 UTC.
Stabilization work via uplifts.

Beta rollout bumped to 100% provided stability is good. 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 6 is the last beta with experimental features still activated. Build starts at 13:00 UTC. Stabilization work via uplifts.

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

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

Last week of the beta cycle. 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.

On a regular 4 weeks beta cycle, this is the last beta and thus the end of beta uplifts, including security bugs for this release (sec-approval+ on Bugzilla). Build starts at 13:00 UTC.

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 shipped to all of our beta population.

We ship Firefox 150 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.