Add Release documentation #8786
Conversation
This adds documentation that describes the release train model, feature flags, versioning system, merge process, and uplift process.
docs/RELEASES.md
Outdated
| Risk to taking this patch (and alternatives if risky): | ||
| ``` | ||
| ## Create K-9 Mail releases |
There was a problem hiding this comment.
This section describes the manual release process, mostly. I think it might be useful to keep in some form, let's say the apocalypse happens and GitHub actions are no longer available or certain steps fail, we'd know how to do it manually.
Otherwise I'd rather suggest this section describes how we trigger releases, what manual intervention is necessary, etc.
If you'd rather do this incrementally I'm fine with adding this section as long as we add a NOTE at the top of the section that we do things automatically now.
docs/RELEASES.md
Outdated
| ### Release a stable version | ||
| When the team decides the `main` branch is stable enough and it's time to release a new stable version, create a new | ||
| maintenance branch (off `main`) using the desired version number with the last two digits dropped followed by `-MAINT`. |
There was a problem hiding this comment.
This might also be confusing as we don't use -MAINT in the new system any more. See former comment though.
coreycb
force-pushed
the
releases-doc
branch
5 times, most recently
from
421f243 to
36fb083
Compare
Moves the manual releasing documentation back to the RELEASING.md file and adds general steps for automated releases to the RELEASES.md file.
| - **Branch:** `main` | ||
| - **Purpose:** Active development of new features and improvements | ||
| - **Release Cadence:** Daily | ||
| - **Audience:** Developers and highly technical users who want to test the bleeding edge of Thunderbird. Nightly builds are unstable and not recommended for daily use. |
There was a problem hiding this comment.
I think this should be daily:
| - **Audience:** Developers and highly technical users who want to test the bleeding edge of Thunderbird. Nightly builds are unstable and not recommended for daily use. | |
| - **Audience:** Developers and highly technical users who want to test the bleeding edge of Thunderbird. Daily builds are unstable and not recommended for production use. |
| - **Purpose:** Active development of new features and improvements | ||
| - **Release Cadence:** Daily | ||
| - **Audience:** Developers and highly technical users who want to test the bleeding edge of Thunderbird. Nightly builds are unstable and not recommended for daily use. | ||
| - **Availability:** Daily builds are available on the Play Store internal channel. APKs are available on ftp.mozilla.org. |
There was a problem hiding this comment.
Maybe we should link directly to the mobile folder at ftp.mozilla.org.
|
|
||
| - On `main`, feature flags are enabled as soon as developers have completed all pull requests related to the feature. | ||
| - On `beta`, feature flags remain enabled unless the feature has not been fully completed and the developers would like to pause the feature. | ||
| - On `release`, feature flags are disabled until an explicit decision has been made to enable the feature for all users. |
There was a problem hiding this comment.
This is not there yet, i created a ticket for implementation: #8801
| - Carrying forward main branch history to beta, and beta branch history to release. | ||
| - No branch history is lost. | ||
| - Git tags are retained in git log. | ||
| - Files/code that is unique per branch can remain that way (e.g. notes files such as changelog_master.xml, version codes). |
There was a problem hiding this comment.
I added a ticket to ensure this is the case for changelog_master.xml: #8802
|
|
||
| ### Uplift Process | ||
|
|
||
| 1. The requestor creates a pull request to the respective target branch with the cherry-picked commits they intend to uplift. |
There was a problem hiding this comment.
At the moment we have a script and a GitHub action that is used for uplifts. It depends on the task: uplift to beta and task: uplift to release labels to cherry-pick to the corresponding branch.
How would that fit into the process?
This adds documentation that describes the release train model, feature flags, versioning system, merge process, and uplift process.