Release Checklist

Overview

These are instructions for preparing a release branch in firefox-ios and starting the next Nightly development cycle. This will cover which steps release management covers for both Firefox iOS and Focus iOS, and which steps developers should cover. Note that we're now having weekly release from main. The release branch is typically created from main on a Friday, with testing throughout the week and released the next week. Please see #firefox-ios-releases channel for more information.

Soft Freeze Tasks

[Release management] Creating a new release branch

This is documented under Release Management/Release Process Checklist Documentation, see firefox-ios steps under Beta Merge Day steps

[Dev team] Handle release branch support tasks

❗ With weekly releases from main backport should very rarely happen.

1. 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.
2. Update Security Advisories if needed (see Security Advisories page.

Hard Freeze Tasks

[Release management] Preparing hard freeze

This is documented under Release Management/Release Process Checklist Documentation, see RC week for iOS

[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 possibly back ported. Each backport needs to be approved before any merge. See section about back ports for more information.
2. Monitor crash rate through Xcode and Sentry.

Backports

❗MANDATORY: on each backport PR created by Mergify we need to fill the backport request.

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. 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.X 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.

Checklist

• Make sure JIRA ticket has the fixed version labels: weekly release.
• Make sure PR title has the appropriate version vXXX.X.
• After backport is available, add the label weekly-release.
• Ensure the build is green and fix any conflicts.
• Fill in the backport request.
• Release management will then either approve or decline. They handle the merge of the PR.

Questions

• What is the current version on main?

  Please check version.txt file to determine which version main is currently on.

• Wait, this means we're not following the Firefox release train schedule?

  We are for major release (ex: v144.0, v145.0, etc). which gets release every month. We get three weeks in between where we're making minor releases cutoff from the main branch. Please be careful if you are adding Strings into the project since those still follow the normal release train.

• How do I backport?

  You can backport to one or more branches by using the mergify command.

  @Mergifyio backport <branch name 2>

• Do I need to set someone from relman as a reviewer on my backport for a weekly release (v1)?

  No. Relman already looks at the PRs that are targeting the release branch. The PR is most likely expected since it is targeting a weekly release and there is a corresponding Jira ticket. If the PR is not expected, Relman will reach out to ask about it.

• I created a backport to a release branch, why is my backport PR still open?

  Relman generally merge PRs closer to the build and release date for a weekly dot release. In the event of an urgent unscheduled release to fix a severe issue, it is preferable to have no other changes already in the release branch that would risk getting a release out.