openclaw-mission-control/docs/release/README.md

Release checklist (maintainers)

This project does not yet have a fully automated release pipeline.

Use this checklist for manual releases and as a place to evolve the process over time.

Before you start

• You have maintainer permissions on abhi1693/openclaw-mission-control
• You know which scope you’re releasing:
  • backend-only change
  • frontend-only change
  • infra/docs-only change
  • full release

1) Pick the release commit

• Ensure you’re on the latest master:

git fetch origin
git checkout master
git reset --hard origin/master

• Identify the commit SHA you want to release (usually origin/master).

2) Verify CI + local checks

• CI is green on the target commit.
• Run the local CI-parity checks:

make setup
make check
make docs-check

3) Smoke test (recommended)

If the change affects runtime behavior (API/UI/auth), do a quick smoke test using the compose stack.

cp .env.example .env
# Configure .env (see repo README for auth mode notes)

docker compose -f compose.yml --env-file .env up -d --build

after_up() {
  echo "Frontend: http://localhost:3000"
  echo "Backend health: http://localhost:8000/healthz"
}

after_up

• Validate basic flows (at minimum):
  • frontend loads
  • backend /healthz returns 200
  • auth mode behaves as expected (local or clerk)

4) Prepare release notes

There is no enforced changelog format yet.

Choose one:

• GitHub Release notes (recommended for now)
• CHANGELOG.md (TODO: adopt Keep a Changelog)

Minimum release notes:

• Summary of key changes
• Any config changes / env var changes
• Any DB migration notes
• Known issues

5) Tag + publish

Tagging convention:

• Use semver tags: vMAJOR.MINOR.PATCH (e.g. v1.4.0).
• Create a GitHub Release from the tag (release notes can be manual for now).
• If the repo already has existing tags/releases, mirror the established convention exactly.

Suggested manual flow:

# Example (adjust once tag conventions are decided)
git tag -a v0.1.0 -m "Release v0.1.0"
git push origin v0.1.0

• Create a GitHub Release from the tag
• Paste the release notes

6) Post-release

• Monitor new issues for regressions
• If you changed public behavior, ensure docs are updated (README + docs pages)

Notes / follow-ups

• Consider adding:
  • automated versioning (changesets / semantic-release)
  • release workflow in .github/workflows/release.yml
  • a CHANGELOG.md