Inconsistent Release Names : 0.4.1 release assets: inner tarballs are named 0.3.2, and the layout differs per asset

[baconpaul]

Noticed while scripting a download of the validator into a plugin's CI. Cosmetic in one sense — the binary is correct in every asset — but between them the two points below mean a downloader has to special-case each platform, and cannot trust the version in the name it unpacks.

1. Every inner tarball says 0.3.2 inside a 0.4.1 release

All five assets on the 0.4.1 release are named 0.4.1. Each of the four that contains a tarball names that tarball 0.3.2:

asset (outer, correct)	contains
clap-validator-0.4.1-127-g152b982-macos-15-aarch64.zip	clap-validator-0.3.2-127-g152b982-macos-15-aarch64.tar.gz
clap-validator-0.4.1-127-g152b982-macos-15-x86_64.zip	clap-validator-0.3.2-127-g152b982-macos-15-x86_64.tar.gz
clap-validator-0.4.1-127-g152b982-macos-universal.zip	clap-validator-0.3.2-127-g152b982-macos-universal.tar.gz
clap-validator-0.4.1-127-g152b982-ubuntu-22.04.zip	clap-validator-0.3.2-127-g152b982-ubuntu-22.04.tar.gz
clap-validator-0.4.1-127-g152b982-windows.zip	clap-validator.exe (no tarball)

The git-describe suffix is identical on both names — 127-g152b982 — so whatever builds the inner name has the right git description and a stale version number beside it. That suggests the two halves come from different sources rather than the description being wrong.

The binary itself is fine:

$ ./binaries/clap-validator --version
clap-validator 0.4.1

2. The five assets unpack three different ways

asset	tarball?	path of the binary once unpacked
macos-15-aarch64	yes	clap-validator
macos-15-x86_64	yes	clap-validator
macos-universal	yes	binaries/clap-validator
ubuntu-22.04	yes	clap-validator
windows	no	clap-validator.exe

Two odd ones out: macos-universal is the only tarball with a binaries/ prefix — plausibly because the universal binary is lipo'd into a directory before packaging — and windows is the only asset with no tarball inside the zip at all.

Reproducing

gh release download --repo free-audio/clap-validator --pattern '*.zip'
for z in *.zip; do echo "== $z"; unzip -l "$z" | sed -n '4p'; done
for z in *.zip; do unzip -q -o "$z"; done
for t in *.tar.gz; do echo "-- $t"; tar tzf "$t"; done

Why it is worth a look

A CI step that wants the validator has to either hardcode a different path per runner, or unpack and go hunting. We ended up with the second:

unzip -q -o ./*.zip
if ls ./*.tar.gz >/dev/null 2>&1; then tar xzf ./*.tar.gz; fi
validator=$(find . -type f \( -name clap-validator -o -name clap-validator.exe \) | head -1)

That works, but it is defensive against packaging rather than against anything real. A consistent <name>/<binary> across assets, and an inner name that agrees with the outer one, would let a downloader spell the path.

Both look like release-script bugs rather than anything in the validator, and neither affects the tool in use — flagging them because the version mismatch in particular is the kind of thing that makes someone think they have downloaded the wrong build.