mirror of https://github.com/meshtastic/Meshtastic-Android.git synced 2026-05-13 17:25:04 -04:00

Files

copilot-swe-agent[bot] 1896970d71 chore(release): add release-please pilot and versioning standards

- docs/versioning.md: full versionCode/versionName policy, multi-track
  monotonicity rationale, release-please SemVer pilot decision record
- version.txt: release-please primary tracking file (2.7.14)
- CHANGELOG.md: bootstrap file to be maintained by release-please
- .github/release-please-config.json: simple release strategy, bootstrap-sha,
  extra-files for config.properties, changelog-sections mapping
- .release-please-manifest.json: initial version manifest
- .github/workflows/release-please.yml: non-shipping pilot, runs on main push,
  creates/updates Release PR and posts step summary with next actions
- config.properties: add x-release-please block markers around VERSION_NAME_BASE
- promote.yml: idempotent production tag push (skip if tag already exists)
- RELEASE_PROCESS.md: add Step 0 (release-please flow) and versioning doc link

Agent-Logs-Url: https://github.com/meshtastic/Meshtastic-Android/sessions/51656e75-0d04-4854-a033-a7064f9f88fb

Co-authored-by: jamesarich <2199651+jamesarich@users.noreply.github.com>

2026-04-22 21:12:01 +00:00

5.0 KiB

Raw Blame History

Meshtastic-Android Release Process

This guide summarizes the steps for releasing a new version of Meshtastic-Android. The process is fully automated via GitHub Actions and Fastlane.

For the versioning policy (versionCode formula, SemVer bump rules, and the release-please integration), see docs/versioning.md.

Overview

The entire release process is managed by a single, manually-triggered GitHub Action: Create or Promote Release.

Trigger: To start a new release or promote an existing one, a developer manually runs the workflow from the GitHub Actions tab.
Inputs: The workflow requires two inputs:
1. version: The base version number you are releasing (e.g., 2.4.0).
2. channel: The release channel you are targeting (internal, closed, open, or production).
Automation: The workflow handles everything automatically:
- Syncs Assets: Fetches the latest firmware/hardware lists, protobuf definitions, and translations (Crowdin).
- Generates Changelog: Creates a clean changelog from commits since the last production release and commits it to the repo.
- Updates Config: Automatically bumps the VERSION_NAME_BASE in config.properties.
- Verifies & Tags: Runs lint checks, builds the app, and only tags the release if successful.
- Deploys: Uploads the build to the correct Google Play track and attaches artifacts (.aab/.apk) to a GitHub Release.
Changelog: Release notes are auto-generated from PR labels. Ensure PRs are labeled correctly to maintain an accurate changelog.

Release Steps

0. Prepare the release (release-please)

The repository runs a release-please pilot that automatically maintains a Release PR on main. This PR proposes the next SemVer version bump (determined from Conventional Commit prefixes) and updates:

CHANGELOG.md
version.txt
VERSION_NAME_BASE in config.properties

When the team is ready to cut a new version:

Review the open Release PR (titled chore(main): release X.Y.Z) in the repository.
Make any changelog edits inside the PR using the BEGIN_COMMIT_OVERRIDE / END_COMMIT_OVERRIDE mechanism (see docs/versioning.md).
Merge the Release PR. release-please will tag the commit as vX.Y.Z and open a draft GitHub Release.
Proceed with the internal build (Step 1 below) using the newly bumped version.

If you need to force a specific version, push an empty commit with Release-As: x.y.z in the body before merging the Release PR.

1. Start an Internal Release

Navigate to the Actions tab in the GitHub repository.
Select the Create or Promote Release workflow.
Click the "Run workflow" dropdown.
Enter the base version (e.g., 2.4.0).
Select the internal channel.
Click "Run workflow".

The workflow will:

Create a new commit on the current branch containing updated assets, translations, and the new changelog.
Tag that commit with an incremental internal tag (e.g., v2.4.0-internal.1).
Build & Deploy the verified artifact to the Play Store Internal track.
Publish a draft pre-release on GitHub.

2. Promote to the Next Channel

Once an internal build has been verified, you can promote it to a wider audience.

Run the Create or Promote Release workflow again with the same base version.
Select the next channel in the sequence (e.g., closed, then open).
The workflow will create a new incremental tag for that channel (e.g., v2.4.0-closed.1) and create a published pre-release on GitHub.

3. Promote to Production

After testing is complete on all pre-release channels, you can create the final public release.

Run the Create or Promote Release workflow one last time.
Use the same base version.
Select the production channel.
The workflow will create a clean version tag (e.g., v2.4.0) and create a published, stable (non-prerelease) release on GitHub.

Note: If the release-please Release PR was merged before this step, the v2.4.0 tag already exists (created by release-please). The production promotion workflow detects this and skips the duplicate tag push gracefully.

4. Post-Release

Verify: Check the Google Play Console to ensure the build is available on the correct track.
Merge: Merge the release branch (if one was used for stabilization) back into main.

Build Attestations & Provenance

All release artifacts are accompanied by explicit GitHub build attestations (provenance). This provides cryptographic proof that the artifacts were built by our trusted GitHub Actions workflow, ensuring supply chain integrity.

You can view and verify provenance in the GitHub UI under each release asset.
For more details, see GitHub's documentation on build provenance.

5.0 KiB Raw Blame History