Compatibility/System Addon/Release Process

Interventions Releases

Module Owner: Dennis Schubert

Generally speaking, new interventions are landed in mozilla-central close to the start of each cycle's soft freeze period, and then ride the trains to Release. By essentially skipping the Nightly cycle, we speed up the process a bit, but we get some stability testing in Beta before the interventions are available to all users.

In cases that are more urgent, we can speed up the process by

• uplifting interventions into Beta at any time during the cycle,
• uplifting the interventions into Release to be shipped with the next dot-release,
• shipping an interventions add-on update out-of-band.

It is up to each release's Interventions Owner to decide if a WebCompat bug is important enough to warrant a fast process.

The normal process: Letting interventions ride the train

For low-priority interventions, the simplest way to ship is to land them in the tree and have them ride the trains like any code change.

1. Build and test the interventions as usual. Submit a Pull Request to the mozilla-extensions/webcompat GitHub repository that does include new interventions, but do not include a version number bump yet.
2. Bump the version number in your local clone of the repo, but do not commit the change yet.
3. Export your changed sources into your mozilla-central checkout. Check the addon's README.md for instructions on how to use the tooling.
4. Make sure ./mach lint browser/extensions/webcompat passes. Since the on-GitHub lints are not exactly the same (primarily, eslint is missing), it's a good idea to run that every time.
5. Submit the patch to Phabricator. You do not need to manually specify a reviewer: the webcompat-reviewers group will be added automatically, sending a notification to everyone in the team.
6. Land the patch. Wait until the patch got merged into mozilla-central to make sure it doesn't get backed out immediately.
7. Export the same sources into your local checkout of android-components. There is tooling to help you with that as well, see addon's README.md. Example Pull Request. To make it easier to keep track of, attach a link to the pull request to the corresponding bug on Bugzilla. If you don't know someone who can review your patch, ask in #fenix-team on Slack.
8. When the patch is merged, you can commit the version number change in the webcompat-addon repository. Make sure to run npm run autoformat before commiting, as that will apply your version number change to package.json and package-lock.json as well.
9. Tag the version with git tag -a v100.0.0 -m 'v100.0.0', and push both your version-bump-commit, and the new tag, to GitHub with git push origin main v100.0.0
10. Make sure that for any intervention you added, you set the sitepatch-applied label GitHub or the [webcompat:sitepatch-applied] whiteboard flag on Bugzilla. Likewise, remove those labels for all interventions you removed.

Uplifting new interventions into Beta

For interventions that are a bit more urgent, you can skip one release cycle and uplift your intervention(s) into Beta. However, do not just request beta uplift for the patch you submitted to mozilla-central:

• It is possible that your patch was not the only change to the addon since the Beta branch got merged. This would cause conflicts, because your new patch won't cleanly apply to Beta.
• Version numbers won't make sense: If you're uplifting a patch for the addon version 101.0.0 into Beta 100, you might make version numbers more confusing, and you also will make rolling out of-of-band updates a bit more complicated.
• It generally is a good idea to limit your Beta uplift to only the important/urgent things. It might not be a wise idea to uplift everything, which might include logic changes, SmartBlock Fixes, and other changes into beta. Keep the risk as low as possible.

Instead, we generally build a separate patch just for Beta.

1. Follow the "normal process", and get your interventions landed in mozilla-central. Wait for the next Nightly build, and make sure your interventions work as you expect.
2. In your local mozilla-central checkout, switch to the mozilla-beta branch/bookmark. If you've never done this before, check the documentation explaining how to work with the mozilla-unified repository.
3. Apply the relevant changes to the Firefox sources.
   • If your patch is simple, you can apply the changes directly to your mozilla-beta tree.
   • If your changes are more complicated, it might be a good idea to use the export tooling in our GitHub repo. You can git checkout the tag corresponding to the version currently shipping in Beta, and then git cherry-pick individual patches from main into your temporary branch. There is no need to publish/merge that branch upstream, as your beta rollout should never include any interventions that aren't also in the main branch anyway.
4. Publish the beta patch to Phabricator and have a webcompat-reviewer rubberstamp the patch. It is a good idea to add a clear indication into the commit message saying that this patch is meant for the Beta branch. Bug 1234567 - Beta - Uplift v101 Interventions into v100 Beta. is an example.
5. Set the approval-mozilla-release? request flag, and explain in the comment why you think this patch should be uplifted to Beta.

A release manager will see your request. If your request is approved, the release managers will push your patch. You do not need to land it, or do anything else!

Uplifting new interventions into Release

If you want your interventions to be available to users very quickly, you can uplift them into mozilla-release and have it shipped in the next dot-release.

1. There is no fixed schedule for dot-releases, but you can reach out to the Release Owner and ask if a dot release is planned, and when it will be shipping. If there is a dot release coming up that fits your needs, let them know that you intend to ship WebCompat interventions in that release.
2. Get your interventions into mozilla-central first, using the "normal process" explained above. Make sure it works!
3. Then, you can follow the "uplifting into Beta" steps. The steps for Beta and Release are exactly the same, except that you're using a different branch/bookmark: mozilla-release instead of mozilla-beta.
4. You can request uplift for Beta and Release at the same time, but since these are two different patches, you have to request both uplifts separately in two comments.

Shipping interventions with an out-of-band System Addon Update

To be done. :denschub is typing this at the moment.

Interventions Release Rotations

Engineers on the Web Compatibility team will rotate on ownership of shipping new versions of our interventions addons, serving as an Intervention Release Owner (IRO). The process will follow a predictable 4 week schedule, mirroring the Firefox release schedule. However, we will attempt to land the interventions 1 week before soft freeze (see the schedule above for dates). Another way to look at this is 2 weeks before release.

A tracking bug for the next release should be filed in Bugzilla (in the Web Compatibility::Interventions component). Bugs for adding or removing interventions in the current release cycle should block this bug.

During bug diagnosis, if a site is identified as a low priority intervention candidate, a action-needssitepatch label is added for the next IRO to take care of during their rotation. High priority interventions should be flagged immediately to the IRO who will then begin the process necessary to ship an off-train intervention.

Candidates for interventions

There is a dedicated action-needssitepatch label on GitHub as well as a Bugzilla bug query for sites that need interventions. During a rotation, you should look at both of these sites and determine which are the most important to work on and ship (or close, if appropriate).

Upcoming Releases

• Version 102 - Ksenia 2022-05-26 2022H1
• Version 103 - Tom 2022-06-23 2022H1

Past Releases

• Firefox 74 (v7) - Ksenia
• Firefox 75 (v8) - Dennis
• Firefox 76 (v9) - Mike
• Firefox 77 (v10) - Ksenia
• Firefox 78 (v11) - Mike
• Firefox 79 (v12) - Dennis
• Firefox 80 (v13) - Karl
• Firefox 81 (v14) - Ksenia
• Firefox 82 (v15) - Tom
• Firefox 83 (v16) - Dennis
• Firefox 84 (v17) - Karl
• Firefox 85 (v18) - Ksenia
• Firefox 86 (v19) - Tom 2021-01-21 2021Q1
• Firefox 87 (v20) - Dennis 2021-02-18 2021Q1
• Firefox 88 (v21) - Karl 2021-03-18 2021Q1
• Firefox 89 (v22) - Ksenia 2021-04-15 2021Q2
• Firefox 90 (v23) - Tom 2021-05-27 2021Q2
• Firefox 91 (v24) - Dennis 2021-07-08 2021Q2
• Firefox 92 (v25) - Karl 2021-08-05 2021H2
• Firefox 93 (v26) - Ksenia 2021-09-02 2021H2
• Firefox 94 (v27) - Tom 2021-09-30 2021H2
• Firefox 95 (v28) - Dennis 2021-10-28 2021H2
• Firefox 96 (v29) - Karl 2021-12-02 2021H2
• Firefox 98 (v30) - Ksenia 2022-02-03 2022H1
• Firefox 99 (v31) - Tom 2022-03-03 2022H1
• Version 100 - Dennis 2022-03-31 2022H1
• Version 101 - Dennis 2022-04-28 2022H1