⚡ Warning: This page hasn't been updated recently and may not be fully accurate or complete. In case of doubt, contact our release managers.

Feature Uplift for Desktop and Mobile

In most cases new feature work should land on mozilla-central (m-c / Nightly). There may be cases when we choose to uplift a feature to Aurora or Beta. This document includes information to help guide the uplift decision and concerns that should be addressed before uplift.

Note that for simple, isolated features, uplift can generally be handled by having a short conversation with the release manager for the release.

Why uplift

The Firefox release process has been designed to balance new feature work and quality. Uplifting a feature subverts this process and reduces the amount of stabilization time available for the feature. Before uplifting a feature it is good to stop and ask why the feature needs to release sooner than the regular process allows.

• Has a commitment been made to release the feature by a certain date?
• Is the feature part of a cross product, coordinated release?
• Is the feature related to a time based market or partner opportunity?

The big question that we always ask is how does releasing the feature sooner help Firefox users?

Considerations for uplift

Localization (l10n)

No string changes are permitted on Aurora and Beta without agreement from l10n. Every effort should be made to maintain string freeze on these branches so as to minimize the impact on the l10n teams. If a feature requires string changes, the l10n team must review before uplift.

UUID changes

UUID changes are acceptable on Aurora but not acceptable on Beta (because they may break add-ons). If a feature requires UUID changes and uplift to Beta, the add-ons team (addons-team at mozilla dot com) must be consulted for assessing the impact to add-ons. If an exception to this rule is granted, the change must be communicated to add-on developers.

Marketing and Comms plan

If there is a reason for uplifting a feature, the feature should typically be accompanied by a marketing and comms plan. Work with these teams early to develop the plan.

Uplift landings

If the feature is sufficiently complex, it may be preferable to have the lead engineer land the changes on all branches themselves vs relying on the sheriffs for uplift.

Informing others

It will likely be beneficial to inform other teams of the uplift. You are encouraged to do so via a post to dev-platform and by discussing the uplift during the Engineering meeting.

Requirements for uplift

Ability to pref off

With less time to stabilize the feature, we need the ability to disable it quickly if the need arises. This is most easily accomplished by creating a pref to disable the feature. Another option is to build the feature so that it can be disabled with ifdef statements.

Automated tests

Automated tests are required before uplifting the feature. The point is to prove to the best of our ability that the feature is stable before landing it on one of our stabilization branches (Aurora and Beta).

Quality Engineering (QE) agreement

Acknowledgement from QE that they can test the feature and preferably a test plan.

Engineering owner

Any issues discovered need to be quickly addressed. An engineering owner or point person must be assigned to address any issues.

Approve / Inform

Approval

Release Manager

The release manager for the release is the decision maker for uplift*.

Desktop changes - Firefox Senior Management

For a substantial, user facing desktop feature, Gavin Sharp, Madhava Enros, and Chad Weiner should sign off on the uplift.

Mobile changes - Fennec Senior Management

For a substantial, user facing mobile feature, Mark Finkle, Brad Lassey, and Karen Rudnitski should sign off on the uplift.

Platform changes - Module owner

For a substantial, user visible change to the platform, such as unprefixing CSS properties, adding new DOM properties, changing the behaviour of existing properties, the module owner should sign off on the uplift.

*Note: In cases of disagreement where an escalation is required, Johnathan Nightingale, VP Firefox, will be the ultimate decision maker.

Inform

Quality Engineering (QE)

The QE release lead for the release is responsible for developing test plans and testing the feature. They should be consulted on the uplift.

Marketing and Comms

Should be informed of the decision to uplift in order to create the marketing and communication plan.

Process

It is best to inform release management of the intent to uplift as soon as it is thought that the feature will be uplifted. Release management will help with informing the right teams and getting the required approvals.

• A new feature starts by landing on m-c
  • The feature must be verified on this channel by QE.
  • Typically the feature should be on m-c for 2-5 days before uplift in order to be tested by the Nightly user base.
• Request Aurora approval for uplift to mozilla-aurora
  • It is highly preferred that new features land as early on Aurora as possible. Remember, the later the feature lands the less time that it will have to be tested on the channel.
• (discouraged) Request Beta approval for uplift to mozilla-beta
  • If a feature is to be uplifted to Beta, it will often be uplifted at the same time as Aurora.
  • Feature uplifts are generally only accepted on Beta up to beta4.