chore(version): stamp the dev version with the UTC time it lands - #1160
Merged
Conversation
The marketplace is served straight from `main`, so adopters install dev versions — the `.devN` suffix reaching a consumer is the normal case, not the exception the docs assumed. And `claude plugin update` compares version strings, not commit SHAs: with every manifest frozen at `0.2.0.dev0` since apache#907, an adopter's update answers "already at the latest version" and never moves the pinned commit, however far behind `main` the installed copy has fallen. Recovery today means `claude plugin marketplace update` plus a full uninstall + reinstall of every plugin, which nobody discovers unaided. Move the suffix to a timestamp: 0.2.0.dev0 -> 0.2.0.dev202609080121. Ordinary `claude plugin update` then works. Minute resolution keeps two bumps on the same day distinct, and the stamp is UTC so it sorts in the order the bumps were made regardless of the contributor's timezone. Bumping stays deliberate rather than per-PR — before pointing adopters at `claude plugin update`, before announcing a change they should take, or when merged work has piled up behind a stale stamp. Requiring it of every PR would put every contributor in conflict with every other over one line, for no gain on changes nobody is waiting for. Mechanical apart from `project.version` and the two docs that stated the old convention: `tools/dev/check-family-plugins.py --fix` propagated the version to the ecosystem manifests and the ten per-family plugin.json files plus their marketplace entries, and `uv lock` refreshed the workspace pin. Generated-by: Claude Code (Opus 5)
potiuk
force-pushed
the
magpie-dev-version-datestamp
branch
from
September 8, 2026 01:31
50c5ebc to
93de21e
Compare
4 tasks
potiuk
added a commit
that referenced
this pull request
Sep 8, 2026
The marker sat at a1cff44, 17 commits behind main. Bumping it alone would claim those commits are described by the specs, so the drift is closed first. Specs updated for what actually shipped: - meta-and-quality-tooling: skill-evals errors, rather than passing, when a case's CLI produced no gradeable output (#1161). - security-reporting: the tracker dashboard projects the current partial bucket to its end-of-bucket value, splitting RATE series (accumulate from zero) from LEVEL series (carry over), and deliberately not projecting mean-based signals (#1158). - project-agnosticism: <PROJECT> and <project> are two placeholders holding different values, and the lint carries both spellings plus spaced variants (#1154). - adapters: the forwarder relay's contact_handle defaults to an org-level shared inbox rather than a named individual (#1135). The multi-hop coordinator case is designed in RFC-AI-0008 and unimplemented. - issue-management-family: the family's eval suites, and the note that --cli runs belong outside a credential-denying sandbox (#1145). Commits needing no spec change: #1152, #1143 and #1156 updated their own specs in-commit; #1149, #1147, #1151 are behaviour-preserving bug fixes; #1155 and #1141 are CI and dependency chores; #1159's spec edits landed with it; #1144 removes hardcoded literals that no spec asserted. One genuine gap recorded rather than papered over: no spec covers marketplace distribution or the dev-version stamping rule from #1160, which is load-bearing because `claude plugin update` compares version strings, not commit SHAs. Logged in adoption-and-setup as wanting its own spec. Generated-by: Claude Code (Opus 5)
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 marketplace is served straight from
main, so adopters install dev versions — the.devNsuffix reaching a consumer is the normal case, not the exception the docs assumed.claude plugin updatecompares version strings, not commit SHAs. With every manifest frozen at0.2.0.dev0since #907, an adopter's update answers "already at the latest version" and never moves the pinned commit, however far behindmainthe installed copy has fallen. Observed today on a real install: three magpie plugins pinned ata1cff444(#1134), 14 commits stale, withclaude plugin updatereporting all three as current. Recovery meansclaude plugin marketplace updateplus a full uninstall + reinstall of every plugin — nobody discovers that unaided.This moves the suffix to a timestamp:
0.2.0.dev0→0.2.0.dev202609080121. Ordinaryclaude plugin updatethen works.Mechanical apart from three files
project.versionand the two docs that stated the old convention were hand-edited. Everything else is generated:tools/dev/check-family-plugins.py --fixpropagated the version to the four ecosystem manifests and the ten per-familyplugin.jsonfiles plus their marketplace entries, anduv lockrefreshed the workspace pin.release-management-config.mdnow carries the bump as a copy-pasteable recipe rather than prose:The docs also drop the claim that "only released versions are ever published to a marketplace, so the PEP 440 suffix never reaches a consumer" — untrue for a marketplace served from a git branch, and the assumption this bug rested on.
Bumping stays deliberate
Not every PR. Requiring a bump of every change would put every contributor in conflict with every other over one line, for no gain on changes nobody is waiting for. The docs land the narrower rule instead: bump when the work needs to reach installed copies — before pointing adopters at
claude plugin update, before announcing a change they should take, or when merged work has piled up behind a stale stamp. A bump is a one-line edit plus a regeneration, so it costs little whenever it is actually wanted.🤖 Generated with Claude Code
https://claude.ai/code/session_01WJopDiCvbwSG6t4k15JE4H