@@ -6,7 +6,7 @@ Thunderbird for Android follows a release train model to ensure timely and predi
### Daily
Daily builds are used for initial testing of new features and changes. Feature flags are additionally used to work on features that are not yet ready for consumption.
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
@@ -21,54 +21,45 @@ After features are stabilized in Daily, they are merged into the Beta branch for
-**Branch:**`beta`
-**Purpose:** Pre-release testing
-**Release Cadence:** Weekly with the option to skip if not needed
-**Merge Cadence:** Every 2 Months
-**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, which is released to the public. It is tested and suitable for general use. Bug fixes and minor updates are periodically applied between major releases. Uplifts to Release are limited to stability/security fixes only.
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 2 months. Minor releases every 2 weeks with the option to skip if not needed.
-**Merge Cadence:** Every 2 months
-**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).
## Example Feature Release Flow
1. A new feature is developed and merged via pull requests into the `main` branch.
2. Every 2 months, `main` is merged into the `beta` branch for external testing and feedback.
3. Every 2 months, `beta` is merged into the `release` branch, and a release is made available to all users.
## Example Bug Release Flow
1. A high-impact bug is fixed and merged via pull request into the `main` branch.
2. After it has received adequate testing on `daily`, the fix is cherry-picked (uplifted) to the `beta` branch and released in the next scheduled beta.
3. After it has received adequate testing on `beta`, the fix is cherry-picked (uplifted) to the `release` branch and released in the next stable minor release.
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
@@ -78,6 +69,45 @@ Thunderbird for Android uses Feature Flags to disable features not yet ready for
- 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
@@ -110,7 +140,7 @@ For example:
## Merge Days
Active development occurs on the `main` branch and becomes part of daily. Every 2 months:
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.
@@ -118,20 +148,26 @@ Active development occurs on the `main` branch and becomes part of daily. Every
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. However, the alpha and 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.2, Thunderbird Beta 9.0b4, and Thunderbird Daily 10.0a1. Here is what happens:
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.2 to 9.0.
- 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 stays the same for each branch. Our application IDs are specific to the branch they are on. For example:
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. Let's say the version code is 20 at 9.0b4, it will be 21 at 10.0b1.
- Likewise, when 9.0b4 becomes 9.0, if the version code on beta is 20 and on release it is 12, then 9.0 becomes 13 and not 21.
- 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're using 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.
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.
@@ -189,43 +225,6 @@ 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.
## Branch Uplifts
If the urgency of a fix requires it to be included in the Beta or Release channel before the next merge, the uplift process is followed.
If possible, uplifts should be avoided and patches should “ride the train” instead, following the merge day cycle.
### 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 performance impact, risk, and reasons the patch is needed on beta.
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.
### 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):
```
## Releases
Releases for both K-9 and Thunderbird for Android are automated with github actions.
