Repository navigation
Let the 0.1.0 release commit pass the version tests - #133
Merged
Merged
Conversation
The Version Packages pull request moves package.json and the VERSION export to 0.1.0 and consumes the pending changesets, and at that commit three test files went red on assertions that pinned the 0.0.x line: - test/sanity.test.ts asserted VERSION matches 0.0.x. The operator moved every package to 0.1.x, so it now pins the 0.x line (a plain 0.minor.patch, never a 1.0, a major or a prerelease). - test/release-readiness.test.ts asserted package.json and VERSION read exactly 0.0.11, the version the readiness audit measured. The version may now also sit on the release line the audit certified, read from the committed surface inventory (certifiedFor 0.1.0): 0.1.0 itself, or a later 0.1.x patch, which the classification rule keeps off the public surface and the surface tests hold exactly. Any other version (0.0.12, 0.2.0, 1.0.0, a prerelease) still reds, and a new case proves that. - Two package-agreement controls in test/docs-set.test.ts graded their seeded installation page against the live package.json, so they flipped with the version. They now grade against this repository's manifest with only the version replaced, on both sides of the 0.0.x line, so each arm is shown to go red in both directions whatever the tree's version is. What still reds at 0.1.0 is the real installation page, which says the package is not installable from the public registry: the gate reads a 0.1.0 manifest as published, so that page changes in the version pull request itself. Verified on a simulated version commit with that page flipped: the full ladder passes. No change under src/. Claude-Session: https://claude.ai/code/session_01U24bnHKNxQWMxmfN7ny7w9
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 Version Packages pull request (#117) moves
package.jsonand theVERSIONexport to 0.1.0 and consumes the pending changesets. At that commit three test files went red on assertions that pinned the 0.0.x line. This makes every change that can be made onmainfirst. No change undersrc/.What changes
test/sanity.test.ts: "starts on the v0.0.x pre-alpha ladder" becomes "stays on the 0.x line": a plain0.minor.patch, never a 1.0, a major or a prerelease. The operator moved every package to 0.1.x.test/release-readiness.test.ts: the two assertions thatpackage.jsonandVERSIONread exactly0.0.11(the version the readiness audit measured) now also accept the release line the audit certified, read from the committed surface inventory (certifiedFor: "0.1.0"): 0.1.0, or a later 0.1.x patch, which the classification rule keeps off the public surface and the surface tests hold exactly. Any other version still reds, and a new case proves it (0.0.12,0.0.10,0.2.0,1.0.0,0.1.0-next.0,0.1).test/docs-set.test.ts: the package-agreement controls graded their seeded installation page against the livepackage.json, so they flipped with the version. They now grade against this repository's manifest with onlyversionreplaced, on both sides of the 0.0.x line, so each direction of the arm is shown to go red (and a truthful page to pass) whatever version the tree is at. One control is added for the direction that could not be shown before.What still changes in the version PR itself
docs-set's real-tree case reads a 0.1.0 manifest as published, so the installation page's "is not installable from the public npm registry today" reds at 0.1.0 and must flip in the version PR. That commit is pushed ontochangeset-release/mainonce this and #132 are merged and the PR has regenerated.Proof on a simulated version commit
A clone with #132 and this branch merged, then
pnpm run version(0.0.11 to 0.1.0, 16 changesets consumed):pnpm testfails exactly 1 test,docs-set > passes every arm of its own gate(installation page)..gitclone URL):typecheck,lint,test(4136 passed),build,attw,format:check,check:docs-set,check:no-emdash,check:no-internal-refs,examples,pack:docs: all exit 0.cosyte/.githubmain on the squashed commit:release-notes.mjs prepareexit 0 ("16 consumed changeset(s): 16 reported, 0 internal-only"),release-notes.mjs assert --expect-version 0.1.0OK,changelog-check.mjs --version 0.1.0not-applicable (the changelog is hand-maintained here).On this branch at 0.0.11:
typecheck,lint,format:checkand the three files (100 tests) pass.https://claude.ai/code/session_01U24bnHKNxQWMxmfN7ny7w9