Make the plugin version identify the bytes it was built from - #161
Merged
Conversation
package.json only moves at release time, so every publish between releases claimed the previous version while carrying different server code. The published plugin read 0.10.0 while built from ffe9130, which is 86 commits past that tag and includes a signalled-shutdown behaviour change that alters exit codes. PROVENANCE.md recorded the truth, but nothing a host displays to a user did, and the publisher exists precisely to stop the distribution channel drifting from source. plugin.json and the Codex manifest now derive their version from git describe. Build metadata after "+" is valid semver and is ignored for precedence, so a build made at a tag still reads 0.11.0 while one made after it reads 0.11.0+94.g4953297. The count is git describe's, meaning commits since the tag along its default walk; rev-list --count and --first-parent answer different questions and give different numbers for the same pair, so the comment names the measure rather than leaving it to be guessed. A checkout with no tags falls back to package.json and says so on stderr. That case is real rather than theoretical: actions/checkout clones at depth 1 by default, which would have silently restored the old behaviour in the republish workflow. That workflow is being fixed in the same change to fetch full history. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
package.jsononly moves at release time, so every publish between releases claimed the previous version while carrying different server code.That is not hypothetical. The published plugin read
0.10.0while built fromffe9130, which is 86 commits past that tag and includes the signalled-shutdown change that alters process exit codes.PROVENANCE.mdrecorded the truth, but nothing a host shows a user did. The publisher exists to stop the distribution channel drifting from source, and it had no defence against drifting in the one field people actually read.The fix
plugin.jsonand the Codex manifest derive their version fromgit describe.Build metadata after
+is valid semver and is ignored for precedence, so a build made at a tag still reads0.11.0, while one made after it reads0.11.0+95.gb09d23d. Verified both ways: a dirty tree produced0.10.0+94.g4953297.dirtyand a clean one0.10.0+95.gb09d23d.The count is
git describe's, meaning commits since the tag along its default walk.rev-list --countand--first-parentanswer different questions and give different numbers for the same pair, so the comment names the measure rather than leaving someone to guess which of the three they are reading. That ambiguity has already produced one wrong number in a cross-lane report today.The trap this nearly walked into
A checkout with no tags falls back to
package.jsonand announces it on stderr.That case is real:
actions/checkoutclones at depth 1 by default, finds no tags, and would have silently restored the old behaviour inside the republish workflow I added earlier today. The workflow has been fixed in the plugin repo to usefetch-depth: 0, so the fallback stays a genuine edge case rather than the normal path.🤖 Generated with Claude Code