«  Firefox 123  »
Go to Release channel

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.

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.

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

If nightly testing was skipped then features should be in a testable state by this date for beta testing.

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.

For features requiring Nightly testing, the QA team appreciates an earlier sign-off from the project teams. If an early sign-off is not available or testing is required only in Beta, 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.

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. Nightly Regression coverage is limited compared to Beta Regression testing throughout the Beta cycle.

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

Built manually just after the merge. It is 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. Uplift requests are open.

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. 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 a second 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 123 at 14:00 UTC (6AM PST) at 25% rollout.

Two weeks after the release, we ship a dot release to address identified quality issues if needed. 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.