A build off a non-release commit produces an archive claiming the released version

[hashkode]

make build on current main produces:

Little-Snitch-Control-v0.2.0.alfredworkflow
ba07e78952de8087413dac0b4a6a9411540757721f53bf10b475033421ab65e1

The published v0.2.0 asset is:

b99ebaa3dbd229ba172009e2aeabfdba74e3b89163b25a86dae183f9871c5331

Same filename, same declared version, different bytes — because workflow/info.plist still reads 0.2.0 while CHANGELOG.md carries a large ## Unreleased section of shipped-but-unreleased work.

This is a trap for exactly the person the project asks to be careful. README tells a security-conscious user to verify the published checksum, and says a local build of a release tag reproduces it. Someone who builds from main instead of the tag gets a mismatch and has no way to tell "I built the wrong commit" from "the release was tampered with" — the two situations the checksum exists to distinguish.

Approach

Per the maintainer: a build id / commit count / short hash on non-release builds.

The rule that makes it unambiguous: the archive carries a plain version only when HEAD is exactly at an annotated release tag. Anything else is a development build and must say so in the filename, so it can never be confused with a published artefact.

at tag v0.2.0   ->  Little-Snitch-Control-v0.2.0.alfredworkflow
3 commits later ->  Little-Snitch-Control-v0.2.0+3.g46f2980.alfredworkflow
dirty tree      ->  Little-Snitch-Control-v0.2.0+3.g46f2980.dirty.alfredworkflow

git describe --tags --long --dirty gives all of this directly.

Tasks

• Teach scripts/build.zsh to detect whether HEAD is at an annotated tag matching the version in info.plist
• Suffix the archive name for development builds; leave release builds byte-identical to today so the published v0.2.0 checksum stays reproducible
• Decide whether the suffix belongs in info.plist's version too — Alfred shows it in the workflow list, which is arguably useful for a development install, but it must not leak into a release build
• Handle a build from a tarball or a shallow clone where git describe fails: fall back to a plain development marker rather than silently producing a release-shaped name
• Assert in tests/package.zsh that a release-shaped filename implies HEAD is at the matching tag
• Correct README's reproducibility wording to say a build of the release tag rather than a local build