During Phase 2b rollout (DTD#4 fix), release.yml failed post-merge on a PR that did not bump VERSION. Root cause was the v1.0 floating tag aliasing v1.8.2's tag object, which made git describe --tags --abbrev=0 return the long form v1.8.2-1-g<sha> instead of v1.8.2.
release.yml then sort -V'd that long string against VERSION=1.8.2 and concluded VERSION had decreased.
The v1.0 alias bug has been fixed separately. But release.yml's logic is still fragile - any future scenario that produces long-form git describe output (detached HEAD, malformed tags, etc.) would surface the same misbehavior.
Recommendation: use git tag -l --sort=v:refname or similar that explicitly walks tag refs rather than relying on describe.
During Phase 2b rollout (DTD#4 fix), release.yml failed post-merge on a PR that did not bump VERSION. Root cause was the v1.0 floating tag aliasing v1.8.2's tag object, which made
git describe --tags --abbrev=0return the long formv1.8.2-1-g<sha>instead ofv1.8.2.release.yml then sort -V'd that long string against VERSION=1.8.2 and concluded VERSION had decreased.
The v1.0 alias bug has been fixed separately. But release.yml's logic is still fragile - any future scenario that produces long-form git describe output (detached HEAD, malformed tags, etc.) would surface the same misbehavior.
Recommendation: use
git tag -l --sort=v:refnameor similar that explicitly walks tag refs rather than relying on describe.