Repository navigation
Version-bump-only regressions surface only on the Version Packages PR — rehearse pnpm run version on main on a schedule and test the bumped tree #20562
Description
Activity
Triage: first touch — closed
not_planned. A new scheduled gate defaults to no until a maintainer names itTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-09-29T04:05Z. ⛔ Not a claim, ⛔ not a dispatch.The class is real, and the precedents are right. #4894, #15255 and #20560 are each a version-sensitive failure first seen on the Version Packages PR, which costs a release cycle. #20566 is the next one, found by reading rather than by the release.
Why it closes now. The card proposes a new scheduled CI job that opens finding cards: a new patrol, a new gate. The standing rule is 「新增门禁默认否」: a new gate lands only when a maintainer names it. The card's own open question (the full Test Core matrix or a curated subset, and a gate for the subset) is the maintainer's cost call.
It re-enters
pm:queuewhen a maintainer names it, answering the matrix-or-subset question. Triage then grades ittoolingunderdomain:devx, with the named release surface as its reach. The question has also been raised in the triage seat's chat.Meanwhile, the fixes stay per defect. #20560 has landed, and #20566 is graded this round.
- added a commit that references this issue
on Sep 29, 2026 Recorded: the maintainer keeps this card closed. No daily version-bump rehearsal on
mainTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-09-30T06:10Z. ⛔ Not a claim, ⛔ not a dispatch.This card was closed
not_plannedon 2026-09-29 under 新增门禁默认否, with the question of reopening it put to the maintainer. The maintainer answered 「同意」 in the live PM chat with the triage seat, 2026-09-30, to triage's recommendation to keep it closed.The recommendation rested on this: the two release faults since (#20613, the publish of the wrong head, and #20747, main red on
Console Pin Gate) were each root-caused and fixed where they arose: #20613 by its release fix (PR #20625), and #20747 by PR #20743. The path-filter gap that let #20747 land is #20765, which is queued. Neither would have been caught by a version-bump rehearsal. A new version-PR-only failure with a measured cost is the trigger to raise this again.
Problem
CI on
mainonly tests the tree at its current version. Some code depends on the version number itself, for example:That code is first exercised after
pnpm run version, and that runs only onchangeset-release/main. So these failures show up at release time, on a PR that nobody can commit to: theversion-prlane rebuilds it withgit reset --hard. The release then waits a full cycle:main;Precedents of the same class
.changeset/*.mdpopulation control makesLint & Repo Gatesred on the Version Packages PR — the release cannot be merged, and main goes red the moment it lands #15255: dispatch-gates red on the Version Packages PR.create-objectstack's runtime-image test hard-codes minor 4 and reds on the 17.5.0 bump.(Advisory-discovery reds such as #20561 are a different class. The daily OSV scan already covers them, and they are out of scope here.)
Proposal
Add a scheduled job (daily, or on each push to
mainthat adds a changeset) that:mainand prepares it withscripts/pm/release-rehearsal-clone.mjs --prepare;pnpm run versionthere, with no push and no publish;create-objectstack, the CLI scaffolds, Scaffold E2E, and the protocol-version sync checks;changeset-release/main.Acceptance
mainbefore any Version Packages PR exists.contents: read, plusissues: writefor the finding card only.Open question for maintainers
The cost trade-off: run the full Test Core matrix on the bumped tree, or only a curated subset. A curated subset needs its own gate so that the list does not rot.
Generated by Claude Code