release: v0.10.2, so the published triage stops blaming pull requests for its own failures - #189
Merged
Conversation
… for its own failures
npm still serves 0.10.1, where running the command this project tells people to
run first, on a public repository, with no token, prints:
20 open pull request(s) read. 14 have something a maintainer checks by hand.
#10586 gci-fun-1 could not be read
...
and exits 0. Nine of those fourteen were GitHub refusing the request after 60
unauthenticated calls an hour, not pull requests needing attention. The fix
merged in #187 and has not reached anybody.
Also ships the README rewrite from #188: it leads with the check nothing else
appears to make, and install drops from four options to one because three of
them were doing nothing.
Verified in the order the last release taught. `pnpm audit` with no severity
filter was run before the tag, not after: 0.10.0 was tagged and then rejected by
the release gate for two moderate advisories, which is how a tag ends up
pointing at something that never shipped.
Checked against the packed tarballs rather than the source tree, since the
source has always worked and that is exactly what hid this: cold install into an
empty directory reports 0.10.2 and triages a real repository. No workspace:* and
no private runtime dependency; 190 KB and 92 KB compressed.
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.
Why
npm still serves 0.10.1. Running the command this project tells people to run
first, on a public repository, with no token:
Exit code
0. Nine of those fourteen were GitHub refusing the request after 60unauthenticated calls an hour, not pull requests needing attention.
The fix merged in #187 and has reached nobody. That is the whole reason for this
release.
Also carries the README rewrite from #188.
Verified in the order the last release taught
pnpm auditwith no severity filter was run before the tag rather thanafter. v0.10.0 was tagged and then rejected by the release gate on two moderate
advisories, which is how a tag ends up pointing at something that never shipped.
Clean this time.
Checked against the packed tarballs, not the source tree. The source has
always worked, and that is exactly what hid the bug:
That output also shows the uniform-note lifting working on the repository that
used to return 15 of 15.
pnpm install --frozen-lockfile,build,test(461),typecheck,lint,format:check: all green. Tarballs carry noworkspace:*and no privateruntime dependency, at 190 KB and 92 KB against a 2 MB limit.
After merge
The SHA pins labelled
# v0.10.1in the Cursor and Copilot guides, and the pinline in the Chinese README, get updated to the v0.10.2 commit in a follow-up.
docs/demo-prs.mdkeeps its older SHA: that line records which build producedthree verified external runs, not what to install.