十处墓碑文案(以及它们生成的 5 个参考文档页)告诉作者某个键"was removed in @objectstack/spec 18"。这些键会随 17.0.0 发布 —— 当前的发布机器根本产不出 18。墓碑文案是给作者看的升级处方,版本号说错会让人以为"我还在 17,这键还能用"。
下游已经踩到:objectui#3101 照着 waitEventConfig.timeoutMs / .onTimeout 的文案,把自己的清理挂在了"等 @objectstack/spec 升到 18 的那个 PR"上 —— 那是个不会到来的事件,而真正的触发点(下一次 17.0.0-rc 刷新)可能就在这几天。
为什么是 17
| 事实 |
值 |
| npm dist-tags |
latest = 16.1.0,rc = 17.0.0-rc.0 —— 17.0.0 从未发布 |
.changeset/pre.json |
mode: "pre", tag: "rc",@objectstack/spec initialVersions = 16.1.0 |
| 这批退役的 changeset |
'@objectstack/spec': major |
| changesets 的算法 |
pre 模式从上一个已发布版本起算:16.1.0 + major = 17.0.0,发成 17.0.0-rc.N。当前 pre 窗口里没有任何路径能到 18 |
packages/spec/src/kernel/protocol-version.ts |
PROTOCOL_VERSION = '17.0.0' —— 而墓碑已经在同一棵树上(如 #4198 的 ab1633122);protocol-version.test.ts 还把它钉死在 package.json 的 major 上,所以它也不能单方面改成 18 |
| ADR-0059 §4 |
删除 → "bump @objectstack/spec to a new major"。相对已发布的 16.1.0,那个 new major 就是 17 |
| 发布列车 |
#3909 "v17 verification tracker — the 17.0.0 train" 仍开着 |
"18" 应该是从在研版本号 17.0.0-rc.0 往上数了一位来的,而 changesets 是从 16.1.0 往上算的。
旁证:同一批文案里 32 处写 17、9 处写 18(spec 源码内)。 那 9 处的共同点只是"在 rc.0 那份 tarball 切出之后才落地" —— 它们全都还在 17 这趟车上。已发布的 17.0.0-rc.0 里 removed in @objectstack/spec 18 出现 0 次,... 17 出现 200 次。
范围
源码(10 处)
跟着一起改
packages/spec/src/data/query.test.ts:94 —— 正则 removed in @objectstack\/spec 18 把错版本号钉住了- 生成的参考文档 12 处 / 5 页(
content/docs/references/{api/contract,api/protocol,api/rest-server,data/data-engine,data/query}.mdx)—— 走生成,别手改
.changeset/wait-timeout-keys-retired.md 正文两处 "protocol 18"(该 changeset 尚未消费)
备选:如果 18 才是本意
那矛盾的就不是文案而是机器:这些墓碑已经带着 major changeset 躺在 16.1.0 起算的 pre 窗口里,PROTOCOL_VERSION 也还是 17.0.0。真要让它们落到 18,得先退出 pre 模式把 17.0.0 切出去、再把这批变更挪到下一趟车 —— 那是个发布计划决定,不是文案改动,而且现在这样"文案说 18、机器发 17"两边对不上,任何一个下游读到的都是错的。我倾向直接把 9+1 处改成 17:与已有的 32 处一致,也与 ADR-0059 §4 的"相对已发布 major"口径一致。
Related
十处墓碑文案(以及它们生成的 5 个参考文档页)告诉作者某个键"was removed in
@objectstack/spec18"。这些键会随 17.0.0 发布 —— 当前的发布机器根本产不出 18。墓碑文案是给作者看的升级处方,版本号说错会让人以为"我还在 17,这键还能用"。下游已经踩到:objectui#3101 照着
waitEventConfig.timeoutMs/.onTimeout的文案,把自己的清理挂在了"等@objectstack/spec升到 18 的那个 PR"上 —— 那是个不会到来的事件,而真正的触发点(下一次 17.0.0-rc 刷新)可能就在这几天。为什么是 17
latest= 16.1.0,rc= 17.0.0-rc.0 —— 17.0.0 从未发布.changeset/pre.jsonmode: "pre",tag: "rc",@objectstack/specinitialVersions = 16.1.0'@objectstack/spec': major17.0.0-rc.N。当前 pre 窗口里没有任何路径能到 18packages/spec/src/kernel/protocol-version.tsPROTOCOL_VERSION = '17.0.0'—— 而墓碑已经在同一棵树上(如 #4198 的ab1633122);protocol-version.test.ts还把它钉死在 package.json 的 major 上,所以它也不能单方面改成 18@objectstack/specto a new major"。相对已发布的 16.1.0,那个 new major 就是 17"18" 应该是从在研版本号
17.0.0-rc.0往上数了一位来的,而 changesets 是从 16.1.0 往上算的。旁证:同一批文案里 32 处写 17、9 处写 18(spec 源码内)。 那 9 处的共同点只是"在 rc.0 那份 tarball 切出之后才落地" —— 它们全都还在 17 这趟车上。已发布的
17.0.0-rc.0里removed in @objectstack/spec 18出现 0 次,... 17出现 200 次。范围
源码(10 处)
packages/spec/src/data/query.zod.ts:177—— nested-select{ field, fields, alias }([P3] data:FieldNode's nested-select object form is declared but nothing produces or consumes it — enforce or remove #4196)packages/spec/src/data/query.zod.ts:216——query.joins([P2] data:QueryASTdeclares 12 members no executor runs — the liveness ledger governs metadata types, not the request surface #4286)packages/spec/src/data/query.zod.ts:229——query.cursor([P2] data:QueryASTdeclares 12 members no executor runs — the liveness ledger governs metadata types, not the request surface #4286)packages/spec/src/data/query.zod.ts:240——query.distinct([P2] data:QueryASTdeclares 12 members no executor runs — the liveness ledger governs metadata types, not the request surface #4286)packages/spec/src/data/query.zod.ts:250——query.windowFunctions([P2] data:QueryASTdeclares 12 members no executor runs — the liveness ledger governs metadata types, not the request surface #4286)packages/spec/src/automation/flow.zod.ts:237——waitEventConfig.timeoutMs(wait声明了超时契约但完全没有实现：onTimeout零读取者，timeoutMs被当成定时时长用 —— showcase 自己在依赖它 #4158)packages/spec/src/automation/flow.zod.ts:244——waitEventConfig.onTimeout(wait声明了超时契约但完全没有实现：onTimeout零读取者，timeoutMs被当成定时时长用 —— showcase 自己在依赖它 #4158)packages/spec/src/api/rest-server.zod.ts:126——api.requireAuth(把 public 从"全局开关的副产品"升级为声明式能力,然后删掉 api.requireAuth 开关 #3963)packages/spec/src/stack.zod.ts:283——api.requireAuth(把 public 从"全局开关的副产品"升级为声明式能力,然后删掉 api.requireAuth 开关 #3963,同一句的第二份)packages/metadata-protocol/src/protocol.ts:3510—— nested-select([P3] data:FieldNode's nested-select object form is declared but nothing produces or consumes it — enforce or remove #4196)跟着一起改
packages/spec/src/data/query.test.ts:94—— 正则removed in @objectstack\/spec 18把错版本号钉住了content/docs/references/{api/contract,api/protocol,api/rest-server,data/data-engine,data/query}.mdx)—— 走生成,别手改.changeset/wait-timeout-keys-retired.md正文两处 "protocol 18"(该 changeset 尚未消费)备选:如果 18 才是本意
那矛盾的就不是文案而是机器:这些墓碑已经带着
majorchangeset 躺在 16.1.0 起算的 pre 窗口里,PROTOCOL_VERSION也还是17.0.0。真要让它们落到 18,得先退出 pre 模式把 17.0.0 切出去、再把这批变更挪到下一趟车 —— 那是个发布计划决定,不是文案改动,而且现在这样"文案说 18、机器发 17"两边对不上,任何一个下游读到的都是错的。我倾向直接把 9+1 处改成 17:与已有的 32 处一致,也与 ADR-0059 §4 的"相对已发布 major"口径一致。Related
wait表单仍提供已退役的waitEventConfig.timeoutMs/.onTimeout—— 下一次 spec rc 刷新会被对账测试点名 objectui#3101 —— 下游照着错文案排期的实例waitEventConfig.timeoutMs/.onTimeout—waitnever had a timeout (#4158) #4198 / [P3] data:FieldNode's nested-select object form is declared but nothing produces or consumes it — enforce or remove #4196 / [P2] data:QueryASTdeclares 12 members no executor runs — the liveness ledger governs metadata types, not the request surface #4286 / 把 public 从"全局开关的副产品"升级为声明式能力,然后删掉 api.requireAuth 开关 #3963 —— 引入这些墓碑的 PR