mirror of
https://github.com/meshtastic/Meshtastic-Android.git
synced 2026-04-20 22:23:37 +00:00
92 lines
5.2 KiB
Markdown
92 lines
5.2 KiB
Markdown
# Meshtastic-Android Release Process
|
|
|
|
This document outlines the steps for releasing a new version of the Meshtastic-Android application. Adhering to this process ensures consistency and helps manage the release lifecycle, leveraging automation via the `release.yml` GitHub Action.
|
|
|
|
**Note on Automation:** The `release.yml` GitHub Action is primarily triggered by **pushing a Git tag** matching the pattern `v*` (e.g., `v1.2.3`, `v1.2.3-open.1`). It can also be manually triggered via `workflow_dispatch` from the GitHub Actions UI.
|
|
|
|
The workflow uses a simple and robust **"upload-only"** model. It automatically:
|
|
* Determines a `versionName` from the Git tag.
|
|
* Generates a unique, always-increasing `versionCode` based on the number of minutes since the Unix epoch. This prevents `versionCode` conflicts and will not overflow until the year 6052.
|
|
* Builds fresh F-Droid (APK) and Google (AAB, APK) artifacts for every run.
|
|
* Creates a **draft GitHub Release** and attaches the artifacts.
|
|
* Attests build provenance for the artifacts.
|
|
* **Uploads** the newly built AAB directly to the appropriate track in the Google Play Console based on the tag.
|
|
|
|
There is no promotion of builds between tracks; every release is a new, independent upload. Finalizing and publishing the GitHub Release and the Google Play Store submission remain **manual steps**.
|
|
|
|
## Prerequisites
|
|
|
|
Before initiating the release process, ensure the following are completed:
|
|
|
|
1. **Main Branch Stability:** The `main` branch (or your chosen release branch) must be stable, with all features and bug fixes intended for the release merged and thoroughly tested.
|
|
2. **Automated Testing:** All automated tests must be passing.
|
|
3. **Versioning and Tagging Strategy:**
|
|
* Tags **must** start with `v` and follow Semantic Versioning (e.g., `vX.X.X`).
|
|
* Use the correct suffixes for the desired release track:
|
|
* **Internal/QA:** `vX.X.X-internal.Y`
|
|
* **Closed Alpha:** `vX.X.X-closed.Y`
|
|
* **Open Alpha/Beta:** `vX.X.X-open.Y`
|
|
* **Production:** `vX.X.X` (no suffix)
|
|
* **Recommendation:** Before tagging, update `VERSION_NAME_BASE` in `buildSrc/src/main/kotlin/Configs.kt` to match the `X.X.X` part of your tag. This ensures consistency for local development builds.
|
|
|
|
## Core Release Workflow: Triggering via Tag Push
|
|
|
|
1. **Create and push a tag for the desired release track.**
|
|
```bash
|
|
# This build will be uploaded and rolled out on the 'internal' track
|
|
git tag v1.2.3-internal.1
|
|
git push origin v1.2.3-internal.1
|
|
```
|
|
2. **Wait for the workflow to complete.**
|
|
3. **Verify the build** in the Google Play Console and with testers.
|
|
4. When ready to advance to the next track, create and push a new tag.
|
|
```bash
|
|
# This will create and upload a NEW build to the 'NewAlpha' (closed alpha) track
|
|
git tag v1.2.3-closed.1
|
|
git push origin v1.2.3-closed.1
|
|
```
|
|
|
|
## Iterating on a Bad Build
|
|
|
|
If you discover a critical bug in a build, the process is simple:
|
|
|
|
1. **Fix the Code:** Merge the necessary bug fixes into your main branch.
|
|
2. **Create a New Iteration Tag:** Create a new tag for the same release phase, simply incrementing the final number.
|
|
```bash
|
|
# If v1.2.3-internal.1 was bad, the new build is v1.2.3-internal.2
|
|
git tag v1.2.3-internal.2
|
|
git push origin v1.2.3-internal.2
|
|
```
|
|
3. **A New Build is Uploaded:** The workflow will run, generate a new epoch-minute-based `versionCode`, and upload a fresh build to the `internal` track. There is no risk of a `versionCode` collision.
|
|
|
|
## Managing Different Release Phases (Manual Steps Post-Workflow)
|
|
|
|
After the `release.yml` workflow completes, manual actions are needed on GitHub and in the Google Play Console.
|
|
|
|
### Phase 1: Internal / QA Release
|
|
* **Tag format:** `vX.X.X-internal.Y`
|
|
* **Automated Action:** The AAB is **uploaded** to the `internal` track and rolled out automatically.
|
|
* **Manual Steps:**
|
|
1. **GitHub:** Find the **draft release**, verify artifacts, and publish it if desired.
|
|
2. **Google Play Console:** Verify the release has been successfully rolled out to internal testers.
|
|
|
|
### Phase 2: Closed Alpha Release
|
|
* **Tag format:** `vX.X.X-closed.Y`
|
|
* **Automated Action:** A new AAB is built and **uploaded** as a **draft** to the `NewAlpha` track.
|
|
* **Manual Steps:**
|
|
1. **GitHub:** Find and publish the **draft release**.
|
|
2. **Google Play Console:** Manually review the draft release and submit it for your closed alpha testers.
|
|
|
|
### Phase 3: Open Alpha / Beta Release
|
|
* **Tag format:** `vX.X.X-open.Y`
|
|
* **Automated Action:** A new AAB is built and **uploaded** as a **draft** to the `beta` track.
|
|
* **Manual Steps:**
|
|
1. **GitHub:** Find and publish the **draft pre-release**.
|
|
2. **Google Play Console:** Manually review the draft, add release notes, and submit it.
|
|
|
|
### Phase 4: Production Release
|
|
* **Tag format:** `vX.X.X`
|
|
* **Automated Action:** A new AAB is built and **uploaded** to the `production` track. By default, it is configured for a 10% staged rollout.
|
|
* **Manual Steps:**
|
|
1. **GitHub:** Find the **draft release**. **Crucially, uncheck "This is a pre-release"** before publishing.
|
|
2. **Google Play Console:** Manually review the release, add release notes, and **start the staged rollout**.
|