Make a build from source say which build it is

[MarcelInTO]

Closes #26.

Every locally built fux reported fux 0.0.0 — a string consistent with every local build ever
made, so the first question on any bug report ("which binary is this?") was answered by nothing.

$ ./bin/fux --version
fux 0.3.0-8-g3738819-dirty

--version, the About box and the usage text now read InformationalVersion through one
accessor, and the Makefile stamps it from git describe --tags --always --dirty. That says
"newer than 0.3.0", "here is the commit", and "this tree matched no commit at all". The tag's
leading v is stripped so it reads like a release with the commit appended. Outside a checkout,
or with no git, the property is not passed and the placeholder stands: fux 0.0.0-dev.

Two things the issue did not anticipate

Both measured rather than reasoned about, because both would have surfaced as a broken release
rather than a failing test.

Since .NET 8 the SDK appends +<commit sha> to InformationalVersion by default. Left
alone, a release would have printed fux 0.9.9+3738819eb78e839964813c5c70d84a08d31f8868 and
failed release.yml's exact --version assertion. Verified by turning the property back on and
watching it happen. Fux.csproj disables it, and a drill check fails if a + ever returns — so
it is caught on the next build rather than the next release.

InformationalVersion does not default to what the release assertions expect on a
prerelease. The issue reasoned that it defaults to Version, so a release keeps printing
fux 0.3.0 — true for 0.3.0, false for 0.2.0-rc.1. It defaults to the whole tag, while
release.yml compares against the numeric core (0.2.0), which is what the About box has always
reported because AssemblyVersion is numeric-only. release.yml now passes
InformationalVersion=core explicitly, so a released binary prints exactly what it printed
before. Confirmed by publishing both 0.9.9 and 0.9.9-rc.1: both report fux 0.9.9.

Coverage

where	asserts
--drill	About box, usage text and VersionString agree; no +<sha> suffix
CI, unstamped	matches a semver pattern — the old assertion demanded three bare numbers and would have failed on 0.0.0-dev
CI, stamped	an InformationalVersion passed in comes out of --version verbatim
CI, Makefile	make -n build still passes the property — a dry run, so it costs nothing

The Makefile check skips out loud rather than silently when git can describe nothing, so a skip
is not read as a pass.

All five drill fixtures pass (390 / 394 / 381 / 368 / 373).

Note

The drill itself still reports 0.0.0-dev, because it runs through dotnet, not make. That is
correct — its checks are about the three surfaces agreeing, which holds either way — but it means
the git describe stamping is pinned by the CI dry-run check rather than by the drill.

🤖 Generated with Claude Code

https://claude.ai/code/session_016X4pgrsMBcsXjqWDo2gBBt