Loading
test(updates): pin the ordering of a dev build's own version stamp
659c8e5e 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.