infigraph --version reports 3.2.6 in both v3.2.7 and v3.2.8 release binaries

[murari316]

Summary

infigraph --version reports infigraph 3.2.6 even when running the actual v3.2.7 or v3.2.8 release binary. infigraph update correctly detects and installs the newer release (binary hash changes, confirming real code was shipped), but the CLI's own --version output never advances past 3.2.6.

Repro

$ infigraph update
Updating infigraph: v3.2.6 → v3.2.8
Downloading infigraph-aarch64-apple-darwin.tar.gz from release v3.2.8...
Installed v3.2.8 to /Users/mlal/.local/bin
...
$ infigraph --version
infigraph 3.2.6

Confirmed this is not a stale-binary/PATH/caching issue on the local machine — downloaded each darwin release asset fresh from GitHub and ran --version directly:

Release tag	SHA-256 (aarch64-apple-darwin)	--version output
v3.2.5	(not recorded)	infigraph 3.2.5 (correct)
v3.2.6	a1019bb2...	infigraph 3.2.6 (correct)
v3.2.7	4adb0943...	infigraph 3.2.6 (stale)
v3.2.8	a1019bb2...	infigraph 3.2.6 (stale)

Note v3.2.6 and v3.2.8 share an identical binary hash for this platform, which is separately suspicious (either an accidental no-op release for aarch64-darwin, or a build artifact reuse bug) — but even the v3.2.7 binary, which does have a distinct hash from v3.2.6 (i.e. new code was actually compiled and shipped), still reports the old version string.

Root cause (suspected, not yet located)

The version string returned by --version (likely CARGO_PKG_VERSION via clap, or a hardcoded constant) was not bumped in the source/Cargo.toml before cutting the v3.2.7 and v3.2.8 releases, even though other code changes did go in. This means:

• Anyone scripting against infigraph --version to gate behavior on a minimum version gets a false negative for two releases running.
• It's impossible to tell from --version alone whether you're actually on v3.2.7/v3.2.8 functionality or still on v3.2.6.

Impact

Users (and infigraph update callers) cannot trust --version to confirm they're on the release they just installed. Combined with the v3.2.6/v3.2.8 aarch64-darwin hash collision, this also raises the question of whether the v3.2.8 release for this platform actually contains the intended changes.

Suggested fix

• Find wherever the CLI's version constant is set (Cargo.toml version, or a hardcoded string passed to clap's Command::version(...)) and confirm the release pipeline actually bumps it before building/tagging.
• Add a release-CI check that fails the release if the built binary's --version output doesn't match the git tag being published.
• Separately verify why v3.2.6 and v3.2.8's aarch64-apple-darwin binaries are byte-identical — confirm the v3.2.8 release actually contains new code for this platform target.