fix(xpkg): 0.0.52 and 0.0.53 were only in the linux section - #168
Merged
Conversation
Both bumps added the entry to `xpm.linux` and nothing else, so macosx and windows stopped at 0.0.51. Linux CI passed and macOS/Windows failed with `mcpplibs.xpkg@0.0.53 not found` -- against a file that literally contains `["0.0.53"]`, just not in their platform's block. The tarball is platform-independent (it is the libxpkg source archive, identical GLOBAL/CN bytes, one sha256), so the entries are identical to linux's. There was never a reason for them to differ; there was only a reason they were missing, which is that I edited one section and checked the file. Verified by parsing and enumerating per platform, not by grepping: linux ok (0.0.53, 0.0.52, 0.0.51) macosx ok (0.0.53, 0.0.52, 0.0.51) windows ok (0.0.53, 0.0.52, 0.0.51) and asserting each new entry's sha256 and that its CN url names its own version. A whole-file grep for `["0.0.53"]` passes on the broken file -- which is exactly what my CI assertion did, so it did not catch this either.
The rule, enforced rather than remembered: Within one descriptor, every platform section that carries any version entry must carry the same set of version entries. A bump is a one-line-looking edit that has to land in N places. Editing `xpm.linux` and reading the file back gives a file that CONTAINS the new version, so the author -- and any whole-file grep -- sees success. The other platforms are simply left behind, and the failure surfaces somewhere else: `mcpplibs.xpkg@0.0.53 not found` on macOS, against a file that literally contains `["0.0.53"]`. That is what happened here twice in a row (0.0.52, then 0.0.53). Linux CI went green both times. The cause was then diagnosed eight times from the outside -- index commit, published artifact, rolling pointer, releases/latest, publish lag, the client version pin, install-vs-use, the lockfile hash -- and every one of those checks was CORRECT, because each asked "is 0.0.53 in the index?" rather than "is it in THIS PLATFORM's section?". Packages that genuinely diverge opt out with `platform_versions_diverge = true` plus a reason. The opt-out is a claim someone made on purpose, which is the difference between a divergence and an omission. Falsified before landing: against the pre-fix xpkg.lua it names `xpm.macosx is missing 0.0.52, 0.0.53` and the same for windows; against the fixed file and all 80 descriptors in the repo it passes. Zero existing divergences, so the rule costs nothing today and only fires on a partial bump.
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.
Both bumps added the entry to
xpm.linuxand nothing else, somacosxandwindowsstopped at 0.0.51.Linux CI passed; macOS and Windows failed with
mcpplibs.xpkg@0.0.53 not found— against a file that literally contains["0.0.53"], just not intheir platform block.
The tarball is platform-independent (the libxpkg source archive, identical
GLOBAL/CN bytes, one sha256), so the entries are identical to linux's.
Verified by parsing and enumerating per platform, not by grepping:
plus an assert on each new entry's sha256 and that its CN url names its own
version. A whole-file grep for
["0.0.53"]passes on the broken file — whichis what my CI-side assertion did, so it did not catch this either.