Skip to Content
InfraRelease checklist

Release Checklist

Use this checklist when preparing a new release. All publish workflows are manual (GitHub Actions → Run workflow); pushing a release branch does not trigger CI.

Per-artifact versions live in the root-level VERSION file and are consumed by every build (gradle/versions.gradle.kts for JVM targets, scripts/ios_generate_version_xcconfig.sh for iOS). There is no fallback — leaving a version blank fails the build.

See the Git strategy for the full branch model; this checklist covers the release-execution steps once you’re on a release/{platform}/{version} branch.

Pre-release

  • Cut release/{platform}/{version} from develop (skip if hotfixing — cut hotfix/{platform}/{version} from the platform’s release tag on main instead).
  • Bump the affected keys in /VERSION — only the artifacts that actually changed.
  • Move ## [Unreleased] → ## [X.Y.Z] — YYYY-MM-DD in the CHANGELOG(s) for each bumped artifact:
    • androidApp/CHANGELOG.md
    • composeApp/CHANGELOG.md (desktop + WASM)
    • server/CHANGELOG.md
  • If iOS is affected: run scripts/ios_generate_version_xcconfig.sh locally and commit the updated iosApp/Configuration/Version.xcconfig.
  • Ensure the test suite passes.
  • Commit as chore(release): {artifact} vX.Y.Z.

Run the publish workflows

In Actions → pick the workflow → Run workflow on main. Each workflow reads its version from VERSION and, on success, pushes an annotated tag {artifact}/v{version} back to the repo (android/v1.0.0, desktop/v1.0.0, server/v1.0.0, wasm/v1.0.0, web/v1.0.0). Re-runs of the same version are no-ops on the tagging step.

  • Publish Android Release → verify APK in Google Drive; android/v{version} tag created.
  • Publish Desktop Release → verify Linux / macOS / Windows artifacts; desktop/v{version} tag created.
  • Publish Server Release → verify image in Artifact Registry, Cloud Run revision healthy; server/v{version} tag created.
  • Publish WASM Web Release → verify at the WASM GCS bucket; wasm/v{version} tag created.
  • Publish Web Release → verify oter-web deploy; web/v{version} tag created.

Post-release

  • Spot-check the deployed artifact end-to-end (Cloud Run /health, Android APK install, desktop dmg/msi/AppImage launches).
  • Confirm the git tag(s) landed on main.
  • Update user-facing docs if any UX changed.

Version-bump example

# 1. Edit VERSION — bump the artifacts you shipped.
$EDITOR VERSION
 
# 2. Move [Unreleased] → [1.1.0] in each affected CHANGELOG.
$EDITOR server/CHANGELOG.md
 
# 3. If iOS bumped, regenerate its xcconfig.
bash scripts/ios_generate_version_xcconfig.sh
 
# 4. Commit the release prep.
git add VERSION server/CHANGELOG.md iosApp/Configuration/Version.xcconfig
git commit -m "chore(release): server v1.1.0"
git push origin main
 
# 5. Trigger the corresponding publish workflow(s) from the Actions tab.
#    Each successful workflow tags the commit as {artifact}/v{version}.

Notes

  • Branch flow — releases are cut on release/{platform}/{version} from develop, merged into main with a merge commit, then back-merged into develop. See the Git strategy for details.
  • iOS is not currently automated in a GitHub Actions workflow. Run scripts/ios_generate_version_xcconfig.sh and build/archive from Xcode until an iOS publish workflow exists.
  • .github/VERSION_HISTORY.md is an older single-file release log. New releases should update the per-component CHANGELOGs above; VERSION_HISTORY.md is kept for the 1.0.0 record only.
Automation optionsGit strategy