-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Release Checklist
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 the gap between the soft freeze and hard freeze is typically three weeks.
This part is 100% covered by the Release Management team. The dev team should not perform these steps.
This is documented under Release Management/Release Process Checklist Documentation, see firefox-ios steps under Beta Merge Day steps
- 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 Targettopic in the #firefox-ios-dev channel. - Back ports bug fixes commits towards the release branch. Make sure to mark any tickets you back port with the proper
fix versionfield in the Jira ticket, and mention any particularities QA need to be careful about when testing. - Update Security Advisories if needed (see Security Advisories page.
This part is 100% covered by the Release Management team. The dev team should not perform these steps.
This is documented under Release Management/Release Process Checklist Documentation, see RC week for iOS
- 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.
- Monitor crash rate through Xcode and Sentry.
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 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-releaseand comment for release management that the work is meant to be merged forvXXX.X - Although devs typically merge normal backports, these specific backports should be handle by release management.
Say we have released v126 and we want a bugfix to go into v126.1, which is the next weekly release
- Create a backport targetting the weekly-release, comment
@Mergifyio backport release/v126(the latest major release) - When that backport PR is created by mergify, go there and add
weekly-releaseto the label field and leave a comment for release management that the work is meant to be merged forV126.1 - Return to your Jira ticket and set the fix version to
weekly-release
- For back port on weekly 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-releaselabel. The dev will be told to create the back port either by product or release management.
Given that main is v3, beta is v2, and release stable is v1;
| What? | Product Manager will | Dev will | Relman will |
|---|---|---|---|
| Need to merge a feature/fix to v3 | X | Merge PR to main | X |
| Need to merge a feature/fix to v2 | X | Merge PR to main, create backport and merge PR to v2 | Ensure PR was merged to main & v2 |
| Need to merge a feature/fix to v1 (pre-release or dot release) | Tag with ‘weekly release’ in jira, notify the developer to create the backports | Merge PR to main, create backport PR to v2 & v1 (you can use mergify with a single command) | Ensure both backports are created & merge them, add to the jira ticket |
| Something is already tagged “Weekly release” (this is always for a v1 release) | X | Merge PR to main, create backport PR to v2 & v1 | Notify developers to create the backports, ensure both backports are created, & merge them at the appropriate time for the dot release (Decide which dot release .1, .2, etc.) |
-
What if I forget to backport one of the branches?
Relman will monitor anything going to the release branches (v1 & v2) and ensure the backport is created. They will either create it or ping you to create it.
-
What if I forget to backport a release feature?
If the PR is tagged by the Product Manager/Dev, Relman will monitor their corresponding release and ping about any tagged PRs with no backport. They will either create it, ping you to create it, or remove the tag.
-
What branch are weekly releases for?
Weekly releases are always for the stable release. (In this case v1)#
-
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 for a weekly release (v1), 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.