Skip to main content

Commit And Release Flow

Use Makefile targets from repo root.

Preferred Commit Flow (Atomic Commands)​

Prefer atomic commands so you can verify each step before the next one:

make check-version
make ruff-test
make mypy-test
make test
make git-add
make git-commit
make git-push

Why this flow is recommended:

  • You can stop immediately when one step fails.
  • Failures are easier to diagnose than in one-shot automation.
  • It keeps commit/release hygiene predictable for the whole team.

Optional local DX mode (same checks, better readability):

make check-version-pretty
make ruff-test-pretty
make mypy-test-pretty
make test-pretty

The *-pretty targets are for local development and use rich text formatting with wrapped output and spaced summaries. Use the plain targets in CI to keep raw logs machine-friendly.

Notes:

  • make git-commit uses the root commit_message.txt file.
  • Prefer this atomic flow over make push unless you are absolutely sure you want one-shot automation.

Optional Release Flow​

Only run this when preparing a release/tag.

  1. Set a new version (must be strictly greater than current VERSION):
make set-version X.Y.ZaN

This writes the version to VERSION and applies it across backend/frontend/tauri packaging files. If release_metadata.md exists, it also refreshes .github/release/metadata.json for the new tag.

  1. If you edit release_metadata.md after the version bump, refresh the tracked metadata JSON:
make metadata

This regenerates .github/release/metadata.json used by the release workflow.

  1. Commit and push (prefer atomic commands):
make ruff-test
make mypy-test
make test
make git-add
make git-commit
make git-push
  1. Tag and publish release workflow:
make git-tag

release_metadata.md format:

  • First non-empty line: release title (markdown heading is allowed).
  • Remaining content: release body.

Next: CI And Release Automation