c2c/k9-mail
c2c/k9-mail
2
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

Repo created

Browse source
This commit is contained in:
Fr4nz D13trich 2025-11-22 13:56:56 +01:00
parent 75dc487a7a
commit 39c29d175b
6317 changed files with 388324 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

122
docs/ci/AUTOMATION.md Normal file
View file

@ -0,0 +1,122 @@
# Release Automation Setup
Release automation is triggered by the workflow_dispatch event on the "Shippable Build & Signing"
workflow. GitHub environments are used to set configuration variables and secrets for each
application and release type.
## Automatic setup
There is a script available for automatic setup, which is helpful if you want to replicate this on
your own repository for devlopment. Please see /scripts/ci/setup_release_automation.
You can run it using:
```bash
python -m venv venv
source venv/bin/activate
pip install requests pynacl
cd .signing
python ../scripts/ci/setup_release_automation -r yourfork/thunderbird-android
```
You will need the following files:
- The signing keys with their default filenames
- A matrix-account.json with the following keys:
```json
{
"homeserver": "matrix-client.matrix.org",
"room": "room id here",
"token": "matrix token here",
"userMap": {
"github_username": "@matrix_id:mozilla.org"
}
}
```
- `play-store-account.json` with the service account json that will do the uploads
- `thunderbird-mobile-gh-releaser-bot.clientid.txt` as a simple file with the client ID of the releaser bot (you can skip this to use GitHub Actions as the user)
- `thunderbird-mobile-gh-releaser-bot.pem` with the private key of the releaser bot
## Build Environments
Build environments determine the configuration for the respective release channel. The following are
available:
- thunderbird_beta
- thunderbird_daily
- thunderbird_release
The following (non-sensitive) variables have been set:
- RELEASE_TYPE: daily | beta | release
- MATRIX_INCLUDES: A JSON string to determine the packages to be built
The following MATRIX_INCLUDES would build an apk and aab for Thunderbird, and an apk for K-9 Mail.
```json
[
{ "appName": "thunderbird", "packageFormat": "apk", "packageFlavor": "foss" },
{
"appName": "thunderbird",
"packageFormat": "bundle",
"packageFlavor": "full"
},
{ "appName": "k9mail", "packageFormat": "apk", "packageFlavor": "foss" }
]
```
The environments are locked to the respective branch they belong to.
## Signing Environments
These environments contain the secrets for signing. Their names follow this pattern:
```text
<appName>_<releaseType>_<packageFlavor>
thunderbird_beta_full
thunderbird_beta_foss
k9mail_beta_foss
```
The following secrets are needed:
- SIGNING_KEY: The base64 encoded signing key, see https://github.com/noriban/sign-android-release for details
- KEY_ALIAS: The alias of your signing key
- KEY_PASSWORD: The private key password for your signing keystore
- KEY_STORE_PASSWORD: The password to your signing keystore
The environments are locked to the respective branch they belong to.
## Publishing Hold Environment
The "publish_hold" is shared by all application variants and is used by the "pre_publish" job.
It has no secrets or variables, but "Required Reviewers" is set to trusted team members who oversee releases. The
effect is that after package signing completes, the publishing jobs that depend on it will not run until released
manually.
![publish hold](assets/publish_hold.png)
## Github Releases Environment
This environment will create the github release. It uses [actions/create-github-app-token](https://github.com/actions/create-github-app-token)
to upload the release with limited permissions.
- RELEASER_APP_CLIENT_ID: Environment variable with the OAuth Client ID of the GitHub app
- RELEASER_APP_PRIVATE_KEY: Secret with the private key of the app
The releases environment is locked to the release, beta and main branches.
If you leave out the environment, the Github Actions user will be used.
## Matrix Notify Environment
This environment will notify about build updates. It requires the following keys:
- MATRIX_NOTIFY_TOKEN: The Matrix token of the user
- MATRIX_NOTIFY_HOMESERVER: The homeserver for the account
- MATRIX_NOTIFY_ROOM: The room id to notify in
- MATRIX_NOTIFY_USER_MAP: A json object that maps github usernames to matrix ids
If you leave out this environment, no notifications will be sent.

242
docs/ci/HISTORICAL_RELEASE.md Normal file
View file

@ -0,0 +1,242 @@
# Create K-9 Mail releases
<div class="warning">
This document contains the historical manual release process for K-9 Mail. Please use the <a href="AUTOMATION.md">automated process</a> instead.
We're keeping this around in case we need to do a manual release.
</div>
## One-time setup
1. Create a `.signing` folder in the root of the Git repository, if it doesn't exist yet.
2. Download the `k9-release-signing.jks` and `k9.release.signing.properties` files from 1Password and place them in the `.signing` folder.
Example `<app>.<releaseType>.signing.properties` file:
```properties
<app>.<releaseType>.storeFile=<path to keystore "../.signing/k9mail.jks">
<app>.<releaseType>.storePassword=<storePassword>
<app>.<releaseType>.keyAlias=<keyAlias>
<app>.<releaseType>.keyPassword=<keyPassword>
```
- `<app>` is the short name of the app, e.g. `k9`
- `<releaseType>` is the type of release, e.g. `release`
### One-time setup for F-Droid builds
1. Install _fdroidserver_ by following
the [installation instructions](https://f-droid.org/docs/Installing_the_Server_and_Repo_Tools).
1. On MacOS, it's best to install the latest version from source, because the version in Homebrew has some issues.
1. Install the android command line tools if not available already.
```shell
brew install --cask android-commandlinetools
```
2. Install latest _fdroidserver_ from source:
```shell
python -m venv fdroidserver-env
source fdroidserver-env/bin/activate
pip install git+https://gitlab.com/fdroid/fdroidserver.git
```
3. To use _fdroidserver_ from the command line, you need to activate the virtual environment before each use:
```shell
source fdroidserver-env/bin/activate
```
4. To deactivate the virtual environment:
```shell
deactivate
```
2. [Sign up for a Gitlab account](https://gitlab.com/users/sign_up) and fork
the [fdroiddata](https://gitlab.com/fdroid/fdroiddata) repository.
3. Clone your fork of the _fdroiddata_ repository.
## Release a beta version
1. Update versionCode and versionName in `app-k9mail/build.gradle.kts`
2. Create change log entries in
- `app-k9mail/src/main/res/raw/changelog_master.xml`
- `app-metadata/com.fsck.k9/en-US/changelogs/${versionCode}.txt`
Use past tense. Try to keep them high level. Focus on the user (experience).
3. Update the metadata link to point to K-9 Mail's data:
`ln --symbolic --no-dereference --force app-metadata/com.fsck.k9 metadata`
4. Commit the changes. Message: "Version $versionName"
5. Run `./gradlew clean :app-k9mail:assembleRelease --no-build-cache --no-configuration-cache`
6. Update an existing installation to make sure the app is signed with the proper key and runs on a real device.
```shell
adb install -r app-k9mail/build/outputs/apk/release/app-k9mail-release.apk
```
7. Tag as $versionName, e.g. `6.508`
8. Copy `app-k9mail/build/outputs/apk/release/app-k9mail-release.apk` as `k9-${versionName}.apk` to Google Drive (MZLA
Team > K9 > APKs)
9. Change versionName in `app-k9mail/build.gradle.kts` to next version name followed by `-SNAPSHOT`
10. Commit the changes. Message: "Prepare for version $newVersionName"
11. Update `gh-pages` branch with the new change log
12. Push `main` branch
13. Push tags
14. Push `gh-pages` branch
### Create release on GitHub
1. Go to https://github.com/thunderbird/thunderbird-android/tags and select the appropriate tag
2. Click "Create release from tag"
3. Fill out the form
- Click "Generate release notes"
- Replace contents under "What's changed" with change log entries
- Add GitHub handles in parentheses to change log entries
- If necessary, add another entry "Internal changes" (or similar) so people who contributed changes outside of the
entries mentioned in the change log can be mentioned via GitHub handle.
- Attach the APK
- Select "Set as a pre-release"
- Click "Publish release"
### Create release on F-Droid
1. Fetch the latest changes from the _fdroiddata_ repository.
2. Switch to a new branch in your copy of the _fdroiddata_ repository.
3. Edit `metadata/com.fsck.k9.yml` to create a new entry for the version you want to release. Usually it's copy & paste
of the previous entry and adjusting `versionName`, `versionCode`, and `commit` (use the tag name).
Leave `CurrentVersion` and `CurrentVersionCode` unchanged. Those specify which version is the stable/recommended
build.
Example:
```yaml
- versionName: "${versionName}"
versionCode: ${versionCode}
commit: "${tagName}"
subdir: app-k9mail
gradle:
- yes
scandelete:
- build-plugin/build
```
4. Commit the changes. Message: "Update K-9 Mail to $newVersionName (beta)"
5. Run `fdroid build --latest com.fsck.k9` to build the project using F-Droid's toolchain.
6. Push the changes to your fork of the _fdroiddata_ repository.
7. Open a merge request on Gitlab. (The message from the server after the push in the previous step should contain a
URL)
8. Select the _App update_ template and fill it out.
9. Create merge request and the F-Droid team will do the rest.
### Create release on Google Play
1. Go to the [Google Play Console](https://play.google.com/console/)
2. Select the _K-9 Mail_ app
3. Click on _Open testing_ in the left sidebar
4. Click on _Create new release_
5. Upload the APK to _App bundles_
6. Fill out Release name (e.g. "$versionCode ($versionName)")
7. Fill out Release notes (copy from `app-metadata/com.fsck.k9/en-US/changelogs/${versionCode}.txt`)
8. Click _Next_
9. Review the release
10. Configure a full rollout for beta versions
11. On the Publishing overview page, click _Send change for review_
12. Wait for the review to complete
13. In case of a rejection, fix the issues and repeat the process
## 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`.
Example: `6.8-MAINT` when the first stable release is K-9 Mail 6.800.
Ideally the first stable release contains no code changes when compared to the last beta version built from `main`.
That way the new release won't contain any changes that weren't exposed to user testing in a beta version before.
1. Switch to the appropriate maintenance branch, e.g. `6.8-MAINT`
2. Update versionCode and versionName in `app-k9mail/build.gradle.kts` (stable releases use an even digit after the
dot, e.g. `5.400`, `6.603`)
3. Create change log entries in
- `app-k9mail/src/main/res/raw/changelog_master.xml`
- `app-k9mail/fastlane/metadata/android/en-US/changelogs/${versionCode}.txt`
Use past tense. Try to keep them high level. Focus on the user (experience).
4. Update the metadata link to point to K-9 Mail's data:
`ln --symbolic --no-dereference --force app-metadata/com.fsck.k9 metadata`
5. Commit the changes. Message: "Version $versionName"
6. Run `./gradlew clean :app-k9mail:assembleRelease --no-build-cache --no-configuration-cache`
7. Update an existing installation to make sure the app is signed with the proper key and runs on a real device.
```shell
adb install -r app-k9mail/build/outputs/apk/release/app-k9mail-release.apk
```
8. Tag as $versionName, e.g. `6.800`
9. Copy `app-k9mail/build/outputs/apk/release/app-k9mail-release.apk` as `k9-${versionName}.apk` to Google Drive (MZLA
Team > K9 > APKs)
10. Update `gh-pages` branch with the new change log. Create a new file if it's the first stable release in a series.
11. Push maintenance branch
12. Push tags
13. Push `gh-pages` branch
### Create release on GitHub
1. Go to https://github.com/thunderbird/thunderbird-android/tags and select the appropriate tag
2. Click "Create release from tag"
3. Fill out the form
- Click "Generate release notes"
- Replace contents under "What's changed" with change log entries
- Add GitHub handles in parentheses to change log entries
- If necessary, add another entry "Internal changes" (or similar) so people who contributed changes outside of the
entries mentioned in the change log can be mentioned via GitHub handle.
- Attach the APK
- Select "Set as the latest release"
- Click "Publish release"
### Create release on F-Droid
1. Fetch the latest changes from the _fdroiddata_ repository.
2. Switch to a new branch in your copy of the _fdroiddata_ repository.
3. Edit `metadata/com.fsck.k9.yml` to create a new entry for the version you want to release. Usually it's copy & paste
of the previous entry and adjusting `versionName`, `versionCode`, and `commit` (use the tag name).
Change `CurrentVersion` and `CurrentVersionCode` to the new values, making this the new stable/recommended build.
Example:
```yaml
- versionName: "${versionName}"
versionCode: ${versionCode}
commit: "${tagName}"
subdir: app-k9mail
gradle:
- yes
scandelete:
- build-plugin/build
```
4. Commit the changes. Message: "Update K-9 Mail to $newVersionName"
5. Run `fdroid build --latest com.fsck.k9` to build the project using F-Droid's toolchain.
6. Push the changes to your fork of the _fdroiddata_ repository.
7. Open a merge request on Gitlab. (The message from the server after the push in the previous step should contain a
URL)
8. Select the _App update_ template and fill it out.
9. Create merge request and the F-Droid team will do the rest.
### Create release on Google Play
1. Go to the [Google Play Console](https://play.google.com/console/)
2. Select the _K-9 Mail_ app
3. Click on _Production_ in the left sidebar
4. Click on _Create new release_
5. Upload the APK to _App bundles_
6. Fill out Release name (e.g. "$versionCode ($versionName)")
7. Fill out Release notes (copy from `app-k9mail/fastlane/metadata/android/en-US/changelogs/${versionCode}.txt`)
8. Click _Next_
9. Review the release
10. Start with a staged rollout (usually 20%)
11. On the Publishing overview page, click _Send change for review_
12. Wait for the review to complete
13. In case of a rejection, fix the issues and repeat the process
14. Once the review is complete, monitor the staged rollout for issues and increase the rollout percentage as necessary
## Troubleshooting
### F-Droid
If the app doesn't show up in the F-Droid client:
- Check the build cycle, maybe you just missed it and it will be available in the next cycle. (The cycle is usually every 5 days.)
- Check [F-Droid Status](https://fdroidstatus.org/status/fdroid) for any issues.
- Check [F-Droid Monitor](https://monitor.f-droid.org/builds) for any errors mentioning `com.fsck.k9`.

3
docs/ci/README.md Normal file
View file

@ -0,0 +1,3 @@
# Thunderbird for Android Release Documentation
Please see the sub-pages for release documentation

259
docs/ci/RELEASE.md Normal file
View file

@ -0,0 +1,259 @@
# Releases
Thunderbird for Android follows a release train model to ensure timely and predictable releases. This model allows for regular feature rollouts, stability improvements, and bug fixes.
## Branches in the Release Train Model
### Daily
Daily builds are used for initial testing of new features and changes. Feature flags are used to work on features that are not yet ready for consumption.
- **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. Daily builds are unstable and not recommended for production use.
- **Availability:** Daily builds are available on the Play Store internal channel. APKs are available on [ftp.mozilla.org](https://ftp.mozilla.org/pub/thunderbird-mobile/).
### Beta
After features are stabilized in Daily, they are merged into the Beta branch for broader testing. Uplifts are limited to bug/security fixes only. The Beta branch serves as a preview of what will be included in the next stable release, allowing for user feedback and final adjustments before general availability.
- **Branch:** `beta`
- **Purpose:** Pre-release testing
- **Release Cadence:** Weekly with the option to skip if not needed
- **Merge Cadence:** Every 4 weeks
- **Audience:** Early adopters and testers. Testers are encouraged to provide error logs and help reproduce issues filed.
- **Availability:** Beta builds are available from the [Play Store](https://play.google.com/store/apps/details?id=net.thunderbird.android.beta) and [F-Droid](https://f-droid.org/packages/net.thunderbird.android.beta).
### Release
This branch represents the stable version of Thunderbird. It is tested and suitable for general use. Uplifts to Release are limited to stability/security fixes only.
- **Branch:** `release`
- **Purpose:** Stable releases
- **Release Cadence:** Major releases every 4 weeks. Minor release 2 weeks after a major release with the option to skip if not needed.
- **Merge Cadence:** Every 4 weeks
- **Audience:** General users. Users may be filing bug reports or leaving reviews to express their level of satisfaction.
- **Availability:** Release builds are available from the [Play Store](https://play.google.com/store/apps/details?id=net.thunderbird.android) and [F-Droid](https://f-droid.org/packages/net.thunderbird.android).
## Sample Release Timeline
| Milestone | Details | Date |
|-------------------------------|-----------|--------|
| TfA 14.0a1 starts | | Aug 28 |
| TfA 12.0 | | Sep 1 |
| TfA 13.0b1 | | Sep 1 |
| TfA 13.0bX | If needed | Sep 8 |
| TfA 12.1 | If needed | Sep 15 |
| TfA 13.0bX | If needed | Sep 15 |
| TfA 14.0a1 soft freeze starts | | Sep 18 |
| TfA 13.0bX | If needed | Sep 22 |
| TfA merge 13.0 beta->release | | Sep 22 |
| TfA merge 14.0 main->beta | | Sep 25 |
| TfA 15.0a1 starts | | Sep 25 |
| TfA 13.0 | | Sep 29 |
| TfA 14.0b1 | | Sep 29 |
## Soft Freeze
A week long soft freeze occurs for the `main` branch prior to merging into the `beta` branch. During this time:
- Risky code should not land
- Disabled feature flags should not be enabled
## Feature Flags
Thunderbird for Android uses Feature Flags to disable features not yet ready for consumption.
- 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.
## Uplifts
Uplifts should be avoided if possible and fixes should ride the train. There are cases, however, where a bug is severe enough to warrant an uplift.
If the urgency of a fix requires it to uplifted to the Beta or Release channel before the next merge, the uplift process must be followed.
### Uplift Criteria
Beta uplifts should:
- Be limited to bug/security fixes only. Features ride the train.
- Not change any localizable strings.
- Have tests, or a strong statement of what can be done in the absence of tests.
- Have landed in main and stabilized on the daily channel.
- Have a comment in the GitHub issue assessing the reasons the patch is needed and risks involved in taking the patch.
Release uplifts should additionally:
- Be limited to stability/security fixes only. Features ride the train.
- Have landed in beta and stabilized on the beta channel.
Examples: Fixes for security vulnerabilies, dataloss, or a crash that affects a large number of users.
### Uplift Process
1. The requestor creates a pull request against the target uplift branch.
2. The requestor adds a comment to the pull request with the Approval Request template filled out.
3. The release driver reviews the uplift request, merging if approved, or closing with a comment if rejected.
Template for uplift requests:
```sh
[Approval Request]
Original Issue/Pull request:
Regression caused by (issue #):
User impact if declined:
Testing completed (on daily, etc.):
Risk to taking this patch (and alternatives if risky):
```
## Versioning System
### Version Names
Thunderbird for Android stable release versions follow the `X.Y` format, where:
- **X (Major version):** Incremented for each new release cycle.
- **Y (Patch version):** Incremented when changes are added to an existing major version.
For beta builds, the suffix `b1` is appended, where the number increments for each beta. For daily builds, the suffix `a1` is appended, which remains constant.
### Version Codes
The version code is an internal version number for Android that helps determine whether one version is more recent than another.
The version code for beta and release is an integer value that increments for each new release.
The version code for daily is calculated based on the date and has the format `yDDDHHmm`:
- **y**: The number of years since a base year, with 2023 as the starting point (e.g., 2024 is 1)
- **DDD**: The day of the year in 3 digits, zero-padded
- **HH**: The hour of the day in 2 digits (00–23)
- **mm**: The minute of the hour in 2 digits
For example:
- `2024-02-09 16:45` → `1 | 040 | 16 | 45` → `10401645`
- `2025-10-12 09:23` → `2 | 285 | 09 | 23` → `22850923`
- `2122-02-09 16:45` → `99 | 040 | 16 | 45` → `990401645`
## Merge Days
Active development occurs on the `main` branch and becomes part of the daily build. Every 4 weeks:
1. `main` is merged into `beta`, for testing.
2. `beta` is merged into `release`, making it publicly available.
On the former, `main` carries over to `beta`, where the community can test the changes as part of “Thunderbird Beta for Testers” (`net.thunderbird.android.beta`) until the next merge day.
On the latter, code that was in beta goes to release, where the general population receives product updates (`net.thunderbird.android`).
When a merge occurs, the version name is carried forward to the next branch, and the alpha/beta suffixes are removed/reset accordingly. For example, let’s say we are shortly before the Thunderbird 9.0 release. The latest releases were Thunderbird 8.1, Thunderbird Beta 9.0b4, and Thunderbird Daily 10.0a1. Here is what happens:
- The `beta` branch is merged to `release`. The resulting version on release changes from 8.1 to 9.0.
- The `main` branch is merged to `beta`. The resulting version on beta changes from 9.0b4 to 10.0b1
- The `main` branch version number is changed from 10.0a1 to 11.0a1
While the version name changes, it must be ensured that the version code remains on the same sequence for each branch. For example:
- If the version code on the beta branch is 20 at 9.0b4, it will be 21 at 10.0b1.
- If the version code on the release branch is 12 at 8.1, it will be 13 at 9.0.
Our application IDs are specific to the branch they are on. For example:
- Beta always uses `net.thunderbird.android.beta` as the app ID for TfA.
- Release always uses `net.thunderbird.android` as the app ID for TfA.
- Release always uses `com.fsck.k9` as the app ID for K-9.
## Milestones
We use GitHub Milestones to track work for each major release. There is only one milestone for the whole major release, so work going into 9.0 and 9.1 would both be in the "Thunderbird 9" milestone. Each milestone has the due date set to the anticipated release date.
There are exactly three open milestones at any given time, some of our automation depends on this being the case. The milestone with the date furthest into the future is the target for the `main` branch, the one closest is the target for the `release` branch. When an uplift occurs, the milestone is changed to the respective next target.
Learn more on the [milestones page](https://github.com/thunderbird/thunderbird-android/milestones)
## Merge Process
The merge process enables various benefits, including:
- Carrying forward main branch history to beta, and beta branch history to release.
- No branch history is lost.
- Git tags are retained in the git log.
- Files/code that is unique per branch can remain that way (e.g. notes files such as changelog_master.xml, version codes).
The following steps are taken when merging main into beta:
1. Lock the main branch with the 'CLOSED TREE (main)' ruleset
2. Send a message to the #tb-mobile-dev:mozilla.org matrix channel to let them know:
- You will be performing the merge from main into beta
- The main branch is locked and cannot be changed during the merge
- You will let them know when the merge is complete and main is re-opened
3. Review merge results and ensure correctness
4. Ensure feature flags are following the rules
5. Push the merge
6. Submit a pull request that increments the version in main
7. Open a new milestone for the new version on github
8. Once the version increment is merged into main, unlock the branch
9. Send a message to the #tb-mobile-dev:mozilla.org channel to notify of merge completion and that main is re-opened
The following steps are taken when merging beta into release:
1. Send a message to the #tb-mobile-dev:mozilla.org matrix channel to let them know:
- You will be performing the merge from beta into release
- You will let them know when the merge is complete
2. Review merge results and ensure correctness
3. Ensure feature flags are following the rules
4. Push the merge
5. Close the milestone for the version that was previously in release
6. Send a message to the #tb-mobile-dev:mozilla.org channel to notify of merge completion
Merges are performed with the `do_merge.sh` script.
The following will merge main into beta:
`scripts/ci/merges/do_merge.sh beta`
And the following will merge beta into release:
`scripts/ci/merges/do_merge.sh release`
Be sure to review merge results and ensure correctness before pushing to the repository.
Files of particular importance are:
- app-k9mail/build.gradle.kts
- app-thunderbird/build.gradle.kts
- app-k9mail/src/main/res/raw/changelog_master.xml
These build.gradle.kts files must be handled as described in "Merge Days" section above. This is part of the do_merge.sh automation.
The app-k9mail/src/main/res/raw/changelog_master.xml should not include any beta notes in the release branch.
## Releases
Releases for both K-9 and Thunderbird for Android are automated with github actions.
Daily builds are scheduled with the [Daily Builds](https://github.com/thunderbird/thunderbird-android/actions/workflows/daily_builds.yml) action and all builds are performed by the [Shippable Build & Signing](https://github.com/thunderbird/thunderbird-android/actions/workflows/shippable_builds.yml) action.
For the historical manual release process, see [Releasing](HISTORICAL_RELEASE.md).
### Release Process
These are the general steps for a release:
1. Perform merge or uplifts. Each release is the result of either a merge or uplift.
2. Draft release notes at [thunderbird-notes](https://github.com/thunderbird/thunderbird-notes).
3. Trigger build via the [Shippable Build & Signing](https://github.com/thunderbird/thunderbird-android/actions/workflows/shippable_builds.yml) action.
4. Review the build results by reviewing the action summary and the git commits resulting from the build.
- Make sure the version code is incremented properly and not wildly off
- Ensure the commits are correct
- Ensure the symlink `app-metadata` points to the right product at this commit
5. Test the build in the internal testing track
- Release versions should be thoroughly tested with the test plan in Testrail
- Beta versions only require a basic smoke test to ensure it installs
6. Promote TfA and K-9 releases to production track in Play Store.
- Set rollout to a low rate (generally 10-30%).
- Betas are only released for TfA. K-9 beta users are advised to use Thunderbird.
7. Wait for Play Store review to complete.
- Release versions of TfA and K-9 have managed publishing enabled. Once the review has completed you need to publish the release
- Beta versions of TfA do not have managed publishing enabled. It will be available once Google has reviewed, even on a weekend.
8. Update F-Droid to new TfA and K-9 releases by sending a pull request to [fdroiddata](https://gitlab.com/fdroid/fdroiddata)
9. Send community updates to Matrix channels, and beta or planning mailing lists as needed.
10. Approximately 24 hours after initial release to production, assess the following before updating rollout to a higher rate:
- Crash rates, GitHub issues, install base, and reviews.

BIN
docs/ci/assets/publish_hold.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 10 KiB