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 remote validation step first:

task release:validate

That checks the current remote main head (or an explicit SHA) against the required GitHub workflows and prints the validated SHA without requiring a clean local checkout. Use task release:next to suggest the next tag, then dispatch the release workflow against that validated SHA 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. task release:validate resolves the exact remote commit and requires successful BMO Ship, BMO Signal, and Required Go Checks workflow runs for that SHA.
2. task release:tag requires the explicit SHA to be contained in origin/main, rejects published releases for the same tag, and dispatches .github/workflows/bmo-release.yml with explicit tag, sha, and release notes inputs.
3. The release workflow creates or refreshes the draft release at that exact SHA, creating the tag remotely when needed.
4. The workflow publishes the GitHub release only after the tagged commit’s source bundle, platform binaries, checksums, SBOM, vulnerability report, and paper book PDF pass verification.
5. If you need a local source-proof rerun while changing release surfaces, use task release:validate:local from a clean main checkout.

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.