Releases and changes

Wraptool does not currently maintain a separate changelog file. The authoritative history is the repository:

• Tags and releases
• Commit history
• Open and completed work

Tags named wraptool-v* publish precompiled binaries for Linux, macOS, and Windows on AMD64 and ARM64. Each Forgejo release also includes a checksums.txt file containing SHA-256 checksums and build-info.txt recording the source commit, Go version, and hashes of the pinned Guix inputs.

Create a release from a clean main branch that exactly matches origin/main:

./release-version patch

The argument can be patch, minor, major, or an explicit stable SemVer such as 0.2.0. The script fetches release tags, calculates and validates the next version, verifies that the release signing key is available, runs the test suite, asks for confirmation, and pushes a signed wraptool-v* tag. Run it on the trusted host where the GPG agent and private key are available, not inside the isolated harness container. Use --dry-run to verify a release without creating a tag or --yes for a non-interactive release.

Confirm the signing-capable secret key is available on the host before running the release command:

gpg --list-secret-keys C8ABC91CAB2DC195B9763877DFABC43C55F2E63A

Release tags are signed by C8ABC91CAB2DC195B9763877DFABC43C55F2E63A. The public key is committed as release-signing-key.asc, making CI verification reproducible and independent of keyserver availability. The same key may be obtained from a public keyserver for independent verification, but always check the complete fingerprint above. CI imports the committed key into a temporary keyring and rejects an invalid, unsigned, wrong-key, or wrong-commit tag before building release artifacts.

If release infrastructure fails after the signed tag is published, do not move or recreate the tag. Run Publish release binaries manually from Forgejo Actions and supply the existing tag name; the workflow restores and verifies the original annotated tag before retrying publication.

The tag is the only source of the release version. The Forgejo workflow derives the artifact names and linker-injected binary version from an exact-match git describe; no version number is maintained in Go source.

The in-binary version is derived from the release tag and Go build VCS information:

wraptool version

It reports the project version, revision when available, whether the checkout was dirty at build time, and the Go version. The MCP wraptool_info tool reports the running server’s build identity and introspection freshness, which is useful when a long-lived server may not match the binary currently on PATH.

Note

Design files under design/ can contain roadmaps and audit findings. They are not a release ledger; verify shipped behavior in source, tests, CLI help, and the documentation pages marked as current reference.