659c8e5 chose "+g<sha>" over "-g<sha>" for the dev channel's stamp on the
grounds that "+" is SemVer build metadata, ignored for precedence, so a build
some commits past v1.2.3 still reads as v1.2.3 rather than as something older.
That claim is load-bearing and was asserted only in prose: if metadata ever
counted for ordering, every dev install would report an upgrade available onto
a release it already contains.
Parse does handle it -- build metadata is stripped before the prerelease tail,
so the "-earlyAccess+g<sha>" order a real build stamps splits correctly too --
but nothing tested it. The existing coverage compares "+k3s1" against "+k3s2",
which is metadata on BOTH sides; the case that matters here is metadata on one
side only, against the bare tag.
Four pairs in the compare table, plus "v0.0.0+g<sha>" in the parse table for a
build pinned to a ref with no tag behind it. Verified by mutation: disabling the
"+" split in Parse fails these cases specifically.
They sit at the end of the table rather than beside the other build-metadata
pairs. The entries are wide and carry no trailing comment, and inserting them
mid-table splits the contiguous comment block, which makes gofmt rewrite the
alignment of seven untouched lines.
flyemoji
646d514a65