chore(release): merge back the real 17.0.0-rc.4 publish commit a10cbc77, byte-true (#6169) - #6177
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📓 Docs Drift CheckThis PR changes 72 package(s): 144 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
hotlong
added
skip-changeset
Claude
github-actions
Bot
added
documentation
hotlong
marked this pull request as ready for review
August 7, 2026 07:39
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.
Fixes #6169
What this is
The head of this PR is the 17.0.0-rc.4 publish commit itself, byte-true:
a10cbc77a1e83a382d4a190879b39d588435a04dchore: version packages (rc)github-actions[bot], 2026-08-07T04:17:39Z36fc93832840fd8dd04ffbe6bf03d3ce4e8b16a1(fix(cli): dev watcher 重建后不再无声——重建成功后自动重启 serve 子进程(默认开,--no-restart 可退) (#5148) #6150)No rebase, no cherry-pick, no amend, zero authored changes on top. The branch ref points at that commit and nothing else —
git ls-remote --heads origin claude/issue-6169-rc4-merge-backreturns exactly that sha.Why byte-true rather than a regenerated version PR: this commit is the truthful record cut at the actual publish point. A version PR regenerated today would attribute everything merged after the cut (#6153, #6156, #5827, #6158, #6154, #6166, #6164, #6172, …) to rc.4 — but npm already carries rc.4 without them. Those changes belong to rc.5.
How to review this (the verification is sha equality, not a line read)
Do not read the 153-file diff line by line. It is the publish commit verbatim; the thing that makes it trustworthy is that it is provably the artifact npm and the tags already point at:
git ls-remote --tags origin | grep 'rc\.4'returns 138 lines = 69 tag objects + 69 peeled (^{}) lines. Every peeled line resolves toa10cbc77a1e83a382d4a190879b39d588435a04d; the set of distinct peeled target shas has size 1. All 69 tag names are@objectstack/*@17.0.0-rc.4.@objectstack/spec@17.0.0-rc.4exists anddist-tags.rcis17.0.0-rc.4(measured on the issue, 2026-08-07 05:30Z).File surface, measured against the parent
36fc938: 153 files, +33604/−79, and nothing outside three categories —**/package.json17.0.0-rc.3to17.0.0-rc.4bump; the other 8 are private, unversioned workspaces (examples/app-crm,examples/app-showcase,examples/app-todo,examples/embed-objectql,packages/connectors/connector-openapi,packages/qa/dogfood,packages/qa/downstream-contract,packages/qa/http-conformance) whose internal dependency ranges moved with the bump**/CHANGELOG.md.changeset/pre.jsoninitialVersionsentry (@objectstack/driver-turso)Zero
.changeset/*.mddeletions — correct for prerelease mode, which records consumption inpre.jsoninstead of deleting the files.content/docs/releases/is untouched (verified: no path under it appears in the diff). No source file, workflow, or config is touched.What it repairs
main's
package.jsonstill say17.0.0-rc.3while npm has served17.0.0-rc.4since 04:17:39Z, and main carries none of rc.4's compiled CHANGELOGs or thepre.jsonconsumption record.a10cbc77is not an ancestor of main (merge-base with main is its own parent36fc938), so today every regeneration ofchangeset-release/mainrecomputes rc.4 again — a version npm already has. Landing this makes the repo state match published reality, and #4935 then computes the next version instead of a collision.Why merging this is safe now (it was not, six hours ago)
The original ordering blocker was that the old
release.ymlauto-published on every push to main whenever the computed next version was absent from npm — so setting main to rc.4 would have made the next push mint rc.5 by itself. #6172 removed that structurally. On current main (b9ebb929):version-pr(Version PR maintenance, push-only) runschangesets/action@v1with aversion:input and nopublish:input at all, pluscreateGithubReleases: false. It can open and refresh the version PR; it has no path to npm.publish(Publish to npm, human-initiated) is gatedif: github.event_name == 'workflow_dispatch'and behind an environment. A push cannot select it.Expected behaviour of the first push run after this merges — this is the acceptance signal, and neither branch of it publishes anything:
version-prregenerateschangeset-release/main, so chore: version packages (rc) #4935 becomes the rc.5 proposal (it currently proposes rc.4). The check on chore: version packages (rc) #4935 afterwards is simply "does it now say 17.0.0-rc.5?".release-integrity(audit + no-mint backfill) reads main at 17.0.0-rc.4, finds 17.0.0-rc.4 already on npm, verifies the existing GitHub Releases / D4 record / runtime image for it, and stays quiet — there is nothing to mint and nothing to backfill.Per the maintainer ruling recorded on #6170 (版本发布必须人工), merging #4935 — i.e. actually releasing — remains a human-only action. This PR does not release anything; it only makes the code match what was already published.
skip-changeset
skip-changesetapplies. This is release bookkeeping: the commit carries its own.changeset/pre.jsonupdate, which is exactly the record of the changesets rc.4 consumed. Adding a new changeset here would be wrong by design — it would enqueue a phantom change into rc.5 describing a release that already shipped, and it would touch.changeset/**beyond what the publish commit itself carries, breaking the byte-true property this PR depends on.Local verification performed
node scripts/check-nul-bytes.mjs→OK (scanned 5897 tracked text file(s); skipped 5 binary, 1 non-regular; no raw ASCII control bytes).pnpm install --frozen-lockfile→Done in 7.7s, exit 0.pnpm-lock.yamlblob is byte-identical before and after (99808482aaf97f5062b549c63f0dc9f8f8c03947), andgit status --porcelainis empty — internal deps areworkspace:*, so the version bumps leave the lockfile untouched, as expected.git merge-tree --write-tree origin/main HEAD→ exit 0, single tree sha, no conflict block, re-verified againstb9ebb929immediately before pushing.Generated by Claude Code