Creating a release branch

These are instructions for preparing a release branch for Fenix Beta release. For reference, the AC release checklist can be found at https://mozac.org/contributing/release-checklist. Instead of updating the AC version manually, you could also wait for automation to update the ac version.

Creating a new Beta release branch

1. Create a branch name with the format releases_v[beta_version].0.0 (for example: releases_v87.0.0) off of the main branch using the GitHub UI. [beta_version] should follow the Firefox Beta version number. See Firefox Release Calendar.

2. Create a pull request with the following commit format Set version to [beta_version].0.0 targeting the releases_v[beta_version].0.0 branch to pin the Android Components VERSION to [beta_version].0.0.

   diff --git a/buildSrc/src/main/java/AndroidComponents.kt b/buildSrc/src/main/java/AndroidComponents.kt
   index 1f3e0dba90..1cfef784e4 100644
   --- a/buildSrc/src/main/java/AndroidComponents.kt
   +++ b/buildSrc/src/main/java/AndroidComponents.kt
   @@ -3,5 +3,5 @@
     * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
   
    object AndroidComponents {
   -    const val VERSION = "73.0.20210223143117"
   +    const val VERSION = "73.0.0"
    }
   

3. Verify that version.txt already refers to the Fenix Beta release version [beta_version].0.0-beta.1 in the releases_v[beta_version].0.0 branch. Bump it up manually if necessary.

4. Announce the new releases_v[beta_version].0.0 branch on Slack in #releaseduty-mobile.

5. Automation should take over after you land your PR into the upstream releases_v[beta_version].0.0 branch. You can verify by clicking on the branch in the UI, and looking for the green/yellow dot that will list links to the running build tasks.

See https://github.com/mozilla-mobile/fenix/pull/22739 for an example.

Starting the next Nightly development cycle

We need to also update version.txt for the main branch in order to prepare beta versions of our Nightly release.

1. Create a new milestone for the [nightly_version] and close the existing [beta_version] milestone. Bump all the remaining open issues in the closed milestone to the new Nightly milestone or remove the tagged milestone depending on what is appropriate.
2. In the main branch, create a pull request to update the version.txt to [nightly_version].0.0-beta.1.
3. Land the updated version.txt into main with a review from someone from relman (#releaseduty-mobile).

See https://github.com/mozilla-mobile/fenix/pull/23640 for an example.

Renew telemetry

After the Beta cut, another task is to renew/remove all soon to expire telemetry probes. What we're looking for is to create a list of telemetry that will expire in [release_version add 2]. See Firefox Release Calendar for the current Release version. There is a script that will help with finding these soon to expire telemetry.

1. Use the helper tools/data_renewal_generate.py to detected and generate files that will help create the following files:

• [release_version add 2]_expiry_list.csv
• [release_version add 2]_renewal_request.txt

2. Upload the [release_version add 2]_expiry_list.csv to Google sheet in this shared Google Drive and contact product to review. For each telemetry listed answer decide for:

• Renew the metric (for how long? Add 12 versions?)
• Choose not to renew (but not delete)
• Choose to remove the metric
• Renew the metric and set to never expire (this should only be for business critical metrics)

3. Note that metrics.yaml is also modified. Once the review is over, continue to modify metrics.yaml to match the decision made in the Google sheet. Make sure to add the PR link and if the telemetry never expires, add the email of the owner as contact.
4. Create a PR for review. Modify [release_version add 2]_renewal_request.txt and paste it to the PR for data review. Make sure to add the answers for:

• When will this collection now expire?
• Why was the initial period of collection insufficient?

Remove unused strings

Now that we made the Beta cut, we can remove all the unused strings marked moz:removedIn <= [release_version subtract 1]. [release_version] should follow the Firefox Release version. See Firefox Release Calendar for the current Release version.

1. File a GitHub issue named "Remove all unused strings marked moz:removedIn <= [release_version subtract 1]".
2. Search and remove all strings marked moz:removedIn="[release_version subtract 1]".
3. Put up a pull request.

Ask for Help

If you run into any problems, please ask any questions on Slack in #releaseduty-mobile.

References:

• https://github.com/mozilla-mobile/fenix/tree/releases_v90.0.0
• https://github.com/mozilla-mobile/fenix/pull/19747