Versioning

Version formats

Build type	Version format
Tagged release	Semantic version tag, e.g. v0.4.2
Local dev build	devel
Local task build	git describe --long output
go install	Go module build info

Run bmo --version to see the version in your installed binary.

Where version comes from

• Runtime variable: internal/version/version.go
• Task builds: Taskfile.yaml injects the version via -ldflags at build time
• VERSION = git describe --long (requires tags)

Release process

Releases are tag-driven, but the tag must point at an exact validated commit. Use the built-in validation step first:

task release:validate

That reruns the public release gates on the current main commit and prints the validated SHA. Use task release:next to suggest the next tag, then tag the validated SHA directly with a notes file:

task release:next
task release:tag TAG=vX.Y.Z SHA=<validated-sha> NOTES_FILE=/path/to/release-notes.md

This flow:

1. Requires branch = main, clean worktree, and passing bmo-go.yml on the explicit SHA
2. Creates a signed annotated git tag on that exact validated commit
3. Pushes the tag without creating an empty release-marker commit
4. Triggers .github/workflows/bmo-release.yml
5. Publishes the GitHub release only after the tagged commit’s source bundle and evidence artifacts pass verification

Release candidates must also publish the validated source bundle and evidence artifacts on the tagged GitHub release.

Verifying a local build

task build
./bmo --version

Notes

• Version bump strategy is determined by svu; always review the proposed next version before confirming.
• If a stricter commit/tag convention is desired, document it separately and keep aligned with svu.