docs/release/RELEASE.md
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.
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.
mainAfter features are stabilized in Daily, they are merged into the Beta branch for broader testing. Uplifts are limited to high-impact bug 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.
betaThis branch represents the stable version of Thunderbird. It is tested and suitable for general use. Uplifts are limited to high-impact bug fixes only.
release| 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 |
A week long soft freeze occurs for the main branch prior to merging into the beta branch. During this time:
Thunderbird for Android uses Feature Flags to disable features not yet ready for consumption.
main, feature flags are enabled as soon as developers have completed all pull requests related to the feature.beta, feature flags remain enabled unless the feature has not been fully completed and the developers would like to pause the feature.release, feature flags are disabled until an explicit decision has been made to enable the feature for all users.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.
Uplifts to Beta and Release should:
Uplifts can include:
Thunderbird for Android stable release versions follow the X.Y format, where:
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.
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:
For example:
2024-02-09 16:45 → 1 | 040 | 16 | 45 → 104016452025-10-12 09:23 → 2 | 285 | 09 | 23 → 228509232122-02-09 16:45 → 99 | 040 | 16 | 45 → 990401645Active development occurs on the main branch and becomes part of the daily build. Every 4 weeks:
main is merged into beta, for testing.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:
beta branch is merged to release. The resulting version on release changes from 8.1 to 9.0.main branch is merged to beta. The resulting version on beta changes from 9.0b4 to 10.0b1main branch version number is changed from 10.0a1 to 11.0a1While the version name changes, it must be ensured that the version code remains on the same sequence for each branch. For example:
Our application IDs are specific to the branch they are on. For example:
net.thunderbird.android.beta as the app ID for TfA.net.thunderbird.android as the app ID for TfA.com.fsck.k9 as the app ID for K-9.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
The merge process enables various benefits, including:
The following steps are taken when merging main into beta:
The following steps are taken when merging beta into release:
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:
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 for both K-9 and Thunderbird for Android are automated with github actions. Daily builds are scheduled with the Daily Builds action and all builds are performed by the Shippable Build & Signing action.
For the historical manual release process, see Releasing.
These are the general steps for a release:
app-metadata points to the right product at this commit