|
1 | 1 | ## Overview ## |
2 | 2 |
|
3 | | -| Monday | Tuesday | Wednesday | Thursday | Friday | |
4 | | -|-----------------|---------------------------|------------------------------|----------------|-------------| |
5 | | -| (Sprint 1 Start)| | | | | |
6 | | -| | Hard code freeze for Beta | | | Code Freeze/Planning |
7 | | -| Sprint 2 Start / Release to Beta / Release Production in Play Store 1% | QA Beta / Promote Release 25% | Promote Release 100% | | | |
| 3 | +Firefox for Android roughly follows the [Firefox Gecko release schedule](https://wiki.mozilla.org/Release_Management/Calendar#Calendars). |
| 4 | +This means we cut a beta at the end of every two sprints, with a full cycle (~4 weeks) of baking on Beta before going to release. Uplifts must be approved by Release Owner (st3fan). |
| 5 | + |
| 6 | +The [Firefox for Android release schedule](https://docs.google.com/spreadsheets/d/1HotjliSCGOp2nTkfXrxv8qYcurNpkqLWBKbbId6ovTY/edit#gid=0) contains more details related to specific Mobile handoffs. |
| 7 | + |
| 8 | +| Monday | Tuesday | Wednesday | Thursday | Friday | |
| 9 | +|-----------------|---------------------------|--------------------------------|-------------------|-----------------| |
| 10 | +| (week 1) | | (Y.2 sprint ended) |Sprint **X.1** starts | | |
| 11 | +| (week 2) | | | | | |
| 12 | +| (week 3) | | Cut **X.1-beta** 12PST | **X.1-beta** QA / Sprint X.2 starts || |
| 13 | +| (week 4) | | | | | |
| 14 | +| (week 5) | | Uplift L10N to **X.1-beta** | Sprint Z.1 starts | | |
| 15 | +| (week 6) | Build X.1-RC with GV Prod for QA | | | | |
| 16 | +| (week 7) | Release X.1 - 5% | Release X.1 20% / Cut Z.1-beta | Release X.1 100% | | |
8 | 17 |
|
9 | 18 | ### Requirements |
10 | | -- Jira account |
| 19 | +- JIRA access |
11 | 20 | - Bugzilla account |
12 | | -- Google Play access (for reviewing crashes) |
| 21 | +- Sentry access |
13 | 22 |
|
14 | 23 | ## Release Checklist |
15 | | -There are two releases this covers: the current sprint that is going out to Beta, and the previous beta that is going to Production. |
16 | | -We will refer to the beta release going out as the *current* sprint release. |
| 24 | +There are two releases this covers: the current sprint that is going out to Beta, and the previous Beta that is going to Production. |
17 | 25 |
|
18 | | -## Start of sprint [Monday, 1st week of sprint] |
19 | | -- [ ] Create milestone for *upcoming* sprint release. (e.g. if you are doing releng for v2.2, create v2.3 milestone) |
20 | | -- [ ] If the upcoming release is a *major* (x.0) release, create an issue in the *upcoming* milestone: "What's New Entry for [*upcoming* release]" to track work for the SUMO page and Google Play release notes, e.g., if the current release is 2.3 but the upcoming one will be 3.0, make a "What's New" issue for 3.0. Product will use this to remember to check in with SUMO. |
21 | | -- [ ] [Create an issue](https://github.com/mozilla-mobile/fenix/issues/new?template=release_checklist.md&title=Releng+for+) in the *upcoming* milestone: "Releng for v[release]". Find an engineer who will handle the next releng task and assign them. |
| 26 | +## Start of Sprint X.1 [Thursday, 1st week of sprint] |
| 27 | +- [ ] [Create an issue](https://github.com/mozilla-mobile/fenix/issues/new?template=release_checklist.md&title=Releng+for+) "Releng for v[release]" to track the current sprint. |
22 | 28 |
|
23 | | -## Release Day [Monday, 3rd week] Beta & Production |
24 | | -- [ ] Promote previous Beta to Release |
25 | | - - [ ] Cherry-pick all merged [automated L10N string PRs](https://github.com/mozilla-mobile/fenix/pull/6156) to add newly translated strings and open a PR against branch that is going to release. (TODO is this safe?) This will require review. |
26 | | - - [ ] Tag the latest released RC version additionally with the tag of the release (v1.0-RC2 -> v1.0) (This can be done as soon as there are no more release blockers, does not need to be on Release Day.) |
27 | | - - [ ] **Verify that the commit hash of the new release matches the most recent RC.** This ensures that the correct version will be released |
28 | | - - [ ] Create a GitHub release build `vX.X.X` (v2.3.0) with the previous Beta branch as the target. |
29 | | - - [ ] Smoketest the signed build |
30 | | - - [ ] Load a url |
31 | | - - [ ] Set up sync |
32 | | - - [ ] Delete browsing data |
33 | | - - [ ] Upload the signed APK from the Taskcluster `signing-production` task to the [release page](https://github.com/mozilla-mobile/fenix/releases) |
34 | | - - [ ] Create a release request in Bugzilla to release to 1%. You can clone [this issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1571967) and `need-info` someone from release management. |
| 29 | +## Sprint X.1 End [Wednesday, 2nd week] Cutting a Beta |
35 | 30 | - [ ] Make a new Beta |
36 | | - - [ ] Create a branch off of master (DO NOT PUSH YET) for the *current* milestone of format `releases/v2.3` (where 2.3 is the *current* milestone). After that, anything landing in master will be part of the next milestone. |
37 | | - - [ ] On the new Beta branch, pin the AC version to the stable version ([example](https://github.com/mozilla-mobile/fenix/commit/e413da29f6a7a7d4a765817a9cd5687abbf27619)) with commit message "Issue #`<this releng issue>`: Pin to stable AC `<version>` for release v2.3" (replacing 2.3 with the version) |
38 | | - - For each issue closed since the last release (run `kotlinc -script automation/releasetools/PrintMentionedIssuesAndPrs.kts` to get a list [see script for details] and paste it into the Releng issue): |
39 | | - - [ ] Ensure it has the correct milestone. |
40 | | - - [ ] Add `eng:qa:needed` flags on each issue that still needs it. |
41 | | - - [ ] Go through the list of issues closed during this sprint in the Done column of the [Sprint Kanban](https://github.com/mozilla-mobile/fenix/projects/9) and make sure they all have the correct milestone. |
| 31 | + - [ ] Create a branch off of master (DO NOT PUSH YET) for the *current* milestone of format `releases/v85.0.0`. After that, anything landing in master will be part of the next release. |
| 32 | + - [ ] On the new Beta branch, pin the AC version to the stable version ([example](https://github.com/mozilla-mobile/fenix/commit/e413da29f6a7a7d4a765817a9cd5687abbf27619)) with commit message "Issue #`<this releng issue>`: Pin to stable AC `<version>` for release v85" |
| 33 | + - [ ] Update the title to include this AC version "Releng for v[release] with AC [version]" |
42 | 34 | - Note: You will need code review to make changes to the release branch after this point, because it is a protected branch. |
43 | 35 | - [ ] Push the branch. |
44 | 36 |
|
45 | | - - [ ] Create a GitHub pre-release build `vX.X.X-beta.1` (v2.3.0-beta.1) with the release branch as the target. This will kick off a build of the branch. You can see it in the mouseover of the CI badge of the branch in the commits view. Builds are found under `signing-*` task. |
46 | | - - If you need to trigger a new RC build, you will need to draft and publish a new (pre-release) release. Editing an existing release and creating a new tag will not trigger a new RC build. |
47 | | - |
48 | | - - [ ] Create a new PI (product integrity) request in Jira. You can clone [this issue](https://jira.mozilla.com/browse/PI-219). |
49 | | - |
50 | | -### SUMO Verification [After Beta release] |
51 | | -- [ ] If the *current* release is a major (x.0) release, review the SUMO article contents of the whats new / other sumo pages and make sure they are accurate with what is in this release. If not, escalate to Product Owner. |
| 37 | + - [ ] Create a GitHub pre-release [Release](https://github.com/mozilla-mobile/fenix/releases) with: |
| 38 | + - [ ] Tag of the format `vX.X.X-beta.1` (v85.0.0-beta.1) |
| 39 | + - [ ] The Target branch is the release branch (releases/v85.0.0) |
| 40 | + - [ ] For the description of the release, look at the [Jira boards](https://jira.mozilla.com/secure/RapidBoard.jspa?rapidView=299&projectKey=FNX&view=reporting&chart=sprintRetrospective&sprint=883) for the X.1 and previous Y.2 sprints and list the major features that were added. This will help with the release notes later on. |
| 41 | + - [ ] Click "Publish release". This will kick off a build of the branch. You can see it in the mouseover of the CI badge of the branch in the commits view. Builds are found under `signing-*` task. |
| 42 | + - If you need to trigger a new RC build, you **MUST** draft and publish a new (pre-release) release (optionally deleting both the release and the tag). Editing an existing release and creating a new tag will **not** trigger a new build. |
| 43 | + - [ ] Send an email to QA at mozilla-mobile-qa@softvision.com with a link to the Taskcluster build (subdirectory of the [Fenix CI](https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.beta)) |
52 | 44 |
|
53 | | -### During Beta Product Integrity (Beta Release until PI green signoff) |
| 45 | +### Bugfix uplifts / Beta Product Integrity (Beta Release until PI green signoff) |
54 | 46 | - [ ] If bugs are considered release blocker then find someone to fix them on master and the milestone branch (cherry-pick / uplift) |
55 | | -- [ ] If needed tag a new RC version (e.g. v1.0-RC2) and follow the submission checklist again. |
| 47 | + - [ ] Add the uplift request to the appropriate row in the [Uplifts document](https://docs.google.com/spreadsheets/d/1qIvHpcQ3BqJtlzV5T4M1MhbWVxkNiG-ToeYnWEBW4-I/edit#gid=0). |
| 48 | +- [ ] If needed tag a new beta version (e.g. v1.0-beta.2) and follow the submission checklist again. |
| 49 | +- [ ] Once there is GREEN QA signoff, file a [release management bugzilla for rollout](https://bugzilla.mozilla.org/show_bug.cgi?id=1664366) |
| 50 | + - [ ] Check Sentry each day for issues on [Firefox Beta](https://sentry.prod.mozaws.net/operations/firefox-beta/) and if nothing concerning, bump release in the bugzilla (5%, 20%, 100%) |
56 | 51 |
|
57 | | -### During Production Release Rollout [Tuesday, Wednesday following Monday Release Day] |
58 | | -- [ ] Check Sentry for new crashes. File issues and triage. |
59 | | -- [ ] Ask Relman in the bug if they see potential blockers on Google Play, and if not, request that they bump the release each day (25% Tu, 100% Wed) |
| 52 | +### Uplifting L10N strings to Beta [Wednesday, 2 weeks after sprint end] |
| 53 | +- [ ] Find the issue ([example](https://github.com/mozilla-mobile/fenix/issues/16381)) filed by L10N / delphine saying string are ready for uplift (it takes 2 weeks for localizers to prepare localization). |
| 54 | +- [ ] If there are new locales that are ready to be added to Release, add them to [l10n-release.toml](https://github.com/mozilla-mobile/fenix/blob/master/l10n-release.toml) |
| 55 | +- [ ] Run the [L10N uplift script](https://github.com/mozilla-mobile/fenix/blob/master/l10n-uplift.py) against the releases/vX.1 branch (releases/v85.0.0). There will likely be conflicts, but if you are confused, they should match the strings in [main/Nightly](https://github.com/mozilla-mobile/fenix/tree/master/app/src/main/res) |
| 56 | +- [ ] Once all conflicts are resolved, tag a new Beta to be released. |
| 57 | +- [ ] Notify delphine in the L10N issue that the strings have been uplifted, and string quarantine can be lifted |
| 58 | + |
| 59 | +### Production Release Candidate [Tuesday, 3 weeks after X.1 Beta was cut] |
| 60 | +- [ ] In android-components: Create a dot release with the GeckoView Production release candidate. |
| 61 | +- [ ] Open a PR against the release branch (releases/v85.0.0) with the AC version bump "Pin to stable AC `<version>` for release v85`. You will need code review. |
| 62 | +- [ ] Create a GitHub pre-release [Release](https://github.com/mozilla-mobile/fenix/releases) with: |
| 63 | + - [ ] Tag of the format `vX.X.X-rc.1` (v85.0.0-rc.1) |
| 64 | + - [ ] The Target branch is the release branch (releases/v85.0.0) |
| 65 | + - [ ] For the description, copy the beta description |
| 66 | +- [ ] Send an email to QA at mozilla-mobile-qa@softvision.com with a link to the Taskcluster build (subdirectory of the [Fenix CI](https://firefox-ci-tc.services.mozilla.com/tasks/index/mobile.v2.fenix.release)) |
60 | 67 |
|
61 | | - Major releases often need to be synchronized with other marketing activities (e.g. blog postings). |
| 68 | +### Production Release [Release day, from [release calendar](https://docs.google.com/spreadsheets/d/1HotjliSCGOp2nTkfXrxv8qYcurNpkqLWBKbbId6ovTY/edit#gid=0)] |
| 69 | +- [ ] Create a GitHub [Release](https://github.com/mozilla-mobile/fenix/releases) with: |
| 70 | + - [ ] Tag of the format `vX.1.X` (v85.1.0) (increment the minor version for new cuts) |
| 71 | + - [ ] The Target branch is the release branch (releases/v85.0.0) |
| 72 | + - [ ] For the description, copy the beta description |
| 73 | + - [ ] file Bugzilla ticket for [release manament](https://bugzilla.mozilla.org/show_bug.cgi?id=1672212) |
62 | 74 |
|
63 | | -## Room for improvement |
64 | | -- [ ] Automate assigning milestones to closed issues (based on date, etc) #6199 |
65 | | -- [ ] Automate assignig `eng:qa:needed` to issues #6199 |
66 | | -- [ ] Automate verification that the commit hash matches the most recent RC |
67 | | -- [ ] Builds generated as part of `signing-production` task look like `public/build/arm64-v8a/geckoBeta/target.apk`. This means that the dev must download, then rename them by hand. Could RM update these to generate `public/build/arm64-v8a/geckoBeta/firefox-preview-v3.0.0-rc.1-arm64-v8a.apk`, or similar? |
| 75 | +- [ ] Check Sentry for new crashes. File issues and triage. |
| 76 | +- [ ] Each day, bump the release rollout if nothing concerning (5%, 20%, 100%) |
0 commit comments