Release Checklist

Overview

These are instructions for preparing a release branch for Firefox iOS and starting the next Nightly development cycle. This will cover which steps release management covers, and which steps developers should cover. Note that the gap between the soft freeze and hard freeze is typically three weeks.

Soft Freeze Tasks

[Release management] Creating a new Beta release branch

This part is 100% covered by the Release Management team. The dev team should not perform these steps.

We'll be taking a snapshot of the current main, and preparing a release candidate from it. See Firefox Release Calendar.

1. Create a branch name with the format releases/v[beta_version] off of the main branch (for example, releases/v114) through the GitHub UI. [beta_version] should follow the Firefox Beta release number. See Firefox Release Calendar.
2. In main update the version from [previous_nightly_version] to [nightly_version]:
   • Run the script update_version.sh in the main branch
   • Create a commit named Set version to [nightly_version].0 for this change.
   • Create a pull request against it and then merge.
   • See example PR
3. Notify the dev team that they can start the new Nightly development cycle per the steps given in the next section ⬇️
4. Trigger the string import GitHub action. Normally triggered on Soft freeze day and Hard freeze day. See documentation here.
5. Change the branch in the scheduled beta build to release/v[beta_version]:
   • View the firefox-ios app in BitRise.
   • Expand the Scheduled list.
   • Click the settings button for SPM_Deploy_Prod_Beta.
   • Select Edit Scheduled Build.
   • Change the Branch to release/v[beta_version].
   • Click Save Changes.
6. Trigger the Firefox-iOS SPM_Deploy_Prod_Beta Bitrise build workflow for the release/v[beta_version] branch
7. Verify the Bitrise build for Firefox-iOS passed, and the app was pushed to TestFlight
8. Add the Internal Group to the TestFlight build to start the iOS review.
9. Create a PI request in Jira for Firefox-iOS v[beta_version]
   • Use this as an example.
10. Post in #firefox-ios-releases channel the PI request link, so devs have access to update it

[Dev team] Handle release Branch support tasks

1. Once release management has created the release branch, notify the team to aim new PRs at the updated fix version by updating the Current PR Version topic in the #ios-watercooler channel.
2. Back ports bug fixes commits towards the release branch. Make sure to mark any tickets you back port with the proper fix version field in the Jira ticket, and mention any particularities QA need to be careful about when testing.
3. Update the PI request. Release management won't update the PI request with comments on what was back ported, so make sure you update the PI request with the latest information as well. Note that builds are preplanned each week to happen on Tuesday, Thursday and Sunday.
4. Update Security Advisories if needed (see Security Advisories page.

Notes for Rapid releases

• Release management can handle the PI request updates since the number of back ports are normally low in those rapid release builds.
• For back port on rapid releases, the dev creates the back port, but the release management will take care to merge it when the time is right. The dev just makes sure the back port is in a mergeable state, tagging the PR with the weekly-release label. The dev will be told to create the back port either by product or release management.

Hard Freeze Tasks

[Release management] Preparing hard freeze

This part is 100% covered by the Release Management team. The dev team should not perform these steps.

1. Check if there are any missing back ports from the previous release.
2. Check if there are any pending PRs.
3. Sync with the iOS team for Hard Freeze.
4. Trigger the string import GitHub action. Normally triggered on Soft freeze day and Hard freeze day. See documentation here.
5. Update PI request if there's been any changes since the last QA sign off.
6. Verify that Firefox iOS release is available in TestFlight.
7. Monitor for QA manual testing sign off for Firefox iOS.
8. Add the External Beta Testers group to the TestFlight Build.
9. Gather release notes.
10. Submit Firefox iOS in the App Store for review.

[Dev team] Supporting the release tasks

1. Fix Release Blockers raised by the QA team. As QA regression tests, they'll open GitHub issues. Watch for new issues and ask Product which could be release blockers. After QA is done testing, you'll get a test report email indicating if the build is green/red. If it's red, there will be a list of critical issues that need to be addressed and back ported. See section about back ports for more information.
2. Monitor crash rate through Xcode and Sentry.

Back port

Make sure to mark any tickets you back port with the proper fix version field in the Jira ticket, and mention any particularities QA need to be careful about when testing. Release management won't update the PI request with comments on what was back ported, so make sure you update the PI request with the latest information as well. Builds are preplanned each week to happen on Tuesday, Thursday and Sunday.

If fixes are required - first merge to main, then use Mergify to uplift the change to the release branch. You need to comment @Mergifyio backport release/vXXX on the PR to uplift. Mergify will then open a PR pointing to the release branch for you. Build should be green before merging to release branch.

[Release management] Go Live day

This part is 100% covered by the Release Management team. The dev team should not perform these steps.

1. Publish Firefox iOS to the App Store.
2. Tag the Firefox iOS release in GitHub.
3. Bump the Firefox iOS version in the release branch to XXX.1