Release

Releasing gocron

Follow these steps in order. Never tag before the full check is green — a release that fails CI is worse than a delayed one.

1. Decide the version (SemVer)

• AppVersion lives in cmd/gocron/gocron.go.
• Feature → bump minor (1.6.7 → 1.7.0). Fix/chore only → bump patch (1.6.7 → 1.6.8). Matches the project's history (v1.5.9 → v1.6.0 was a minor).
• If unsure whether the batch is "feature" or "fix", ask the user.

2. Bump version + align migration

• Edit AppVersion in cmd/gocron/gocron.go.
• ToNumberVersion maps the string to an int (1.7.0 → 170). If this release adds a DB migration, its versionId + upgradeForNNN in internal/models/migration.go MUST use that same number (e.g. 170), and the Upgrade chain must include it. Add a migration test.
• If there is NO schema change, only AppVersion changes.

3. Run the full CI check locally (mandatory gate)

Run the /verify command (or the steps in CLAUDE.md → "Pre-commit / release checks"): gofmt, go vet, golangci-lint, go test -race, and the frontend build/typecheck/lint. go build/go test alone are NOT sufficient — lint is a separate gate. Fix everything until all steps are green.

4. Commit, merge, tag

• Commit the version bump: chore(release): bump version to X.Y.Z (short subject; commitlint rejects > 100 chars).
• Merge the release branch into master (fast-forward preferred).
• Confirm GitHub Actions is green on the pushed commit before tagging.
• Tag and push: git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.Z (annotated tag). release.yml listens on v* tags to build/publish artifacts.

5. If a release migration changes existing data

Migrations that rewrite existing rows (e.g. remapping notify_status) can't be undone — remind the user to back up the database before upgrading, and note the change in the release notes.

Guardrails

• Do not tag on a red or unverified CI.
• Do not develop/commit directly on master; use a branch.
• Do not add Co-Authored-By lines to commits.