Release Process

This page documents the normal Mindwtr release flow at a practical level. It is intended for maintainers working from the repository.

Source Files

Release automation and version metadata are centered in:

Make sure main is in the intended release state and commit any pre-release work first.
- If the previous version is already released, put follow-up fixes under docs/release-notes/unreleased.md and link it from CHANGELOG.md until the next patch version is prepared, for example v0.9.1 after v0.9.0.
Bump the version with:

bash

./scripts/bump-version.sh 0.x.y

This updates workspace package versions and bumps the Android versionCode.

Run the release hard gates before tagging:
- Type/test gate:
  - bun run test
  - bun run typecheck
  - bun run native:test
- FOSS/static gate:
  - inspect git diff vPREV..HEAD -- apps/mobile/package.json
  - inspect F-Droid/FOSS config files (apps/mobile/plugins/android-manifest-fixes.js, apps/mobile/scripts/, .github/workflows/release-android-foss.yml, config/izzyonandroid.yml)
  - run python3 scripts/ci/repair-package-lock.py --check apps/desktop/package-lock.json
- CloudKit schema gate:
  - inspect synced schema files against the previous tag
  - if a new CloudKit-backed field or record type was added, update/deploy the production schema before release
Prepare or update release notes and metadata:
- docs/release-notes/<version>.md
- docs/release-notes/google-play/<version>.txt
- metadata/*/release_notes.txt
- metadata/*/changelogs/<androidVersionCode>.txt
- metadata/metadata.json
- apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml
Update wiki pages in wiki/ when release/docs process details changed. Do not run git in a separate .wiki checkout.
Review the resulting version and metadata changes carefully.
Commit the release prep:

bash

git add -A
git commit -m "chore(release): v0.x.y"

bash

git tag v0.x.y

bash

git push origin main --tags

Let GitHub Actions publish the platform artifacts and any downstream packaging jobs.

At minimum, verify:

release notes exist and match the actual changes
package versions are aligned across the monorepo
Android versionCode was incremented
desktop package lock passes repair-package-lock.py --check
FOSS config still strips blocked permissions and keeps only intentional ones
CloudKit-backed schema did not change, or the production schema was updated first
store/release metadata changes are intentional and scoped per platform
mobile store categories in the consoles are still correct: Google Play Productivity > Task Management and App Store primary category Productivity
Google Play locale bodies fit the 500-character API limit

For larger releases, also verify:

desktop updater metadata
mobile store metadata / Fastlane inputs
wiki/docs changes for user-visible features
cross-backend sync smoke with a small seed dataset: add, update, delete, and attachment transfer should converge across Cloud, WebDAV/file sync, and any platform-native backend available to the release tester; a second sync should report no new conflicts

Versioned release notes live in docs/release-notes/.

Guidelines:

keep the top summary user-facing
include the important fixes/features first
list notable commits when helpful
keep Google Play snippets in docs/release-notes/google-play/ aligned when needed
update metadata/*/release_notes.txt for App Store release notes
add the new Android changelog file under metadata/*/changelogs/<versionCode>.txt
keep Microsoft Store release notes in metadata/metadata.json aligned with the same release
add or refresh the top AppStream entry in apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml

After the tag is pushed:

If a bad release is detected: