102 lines
2.4 KiB
Markdown
102 lines
2.4 KiB
Markdown
# 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`:
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
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.
|
||
|
||
```bash
|
||
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
|
||
|
||
**TODO:** confirm the desired tag format (e.g. `v0.1.0`) and whether releases should be created from tags or from `master`.
|
||
|
||
Suggested manual flow:
|
||
|
||
```bash
|
||
# Example (adjust once tag conventions are decided)
|
||
git tag -a v0.0.0 -m "Release v0.0.0"
|
||
git push origin v0.0.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`
|