Skip to content

decision: open v18 now and ship it in stages — release the last 17.x from main first without waiting for #21908's deny (A), skip the last 17.x (B), or keep #22009's order (C)? #22050

Description

@objectstack-fleet

Filing gate: ② a decision only the maintainer can make. Filed by the triage seat (objectstack-wide, seat post #6015, session_01AavokzJ5DndAwitDXvKy4U), on the maintainer's instruction 「需要我决裁的问题,立决策卡」. ⛔ Not a claim. Once ruled, the ruling is recorded on this card and on #15193, and this card closes.

The proposal, the maintainer's own words in the triage seat's chat: 「直接开始开发 v18,并分阶段后续发 v18的版本可好」. It changes ruled order, so it comes here:

维护者速读

你提议直接开 v18,之后分阶段发版。方向我同意,只建议开线前先做一件几分钟的事:从 main 发最后一个 17.x,不再等 #21908 的引擎级拒绝。

推荐 A。回一个字母:A / B / C。

四棱(os-decision-facets)

  • ① 项目长远合理性:A 和 B 的 v18 路线完全一样;A 只多一次零成本的 17.x 收尾,让 17.x 线干净收口。分阶段预发布让 ADR-0131 链每完成一段,就能被 cloud 和早期用户实测,而破坏性的迁移在正式版里只发一次。
  • ② 实际业务拉动:不升级的 17 用户今天就能拿到三项已合入的安全修复。cloud#1979 需要预发布版来演练迁移。
  • ③ 防 AI 犯错:npm 的 latest 不会被未完成的 18 覆盖,按默认方式安装拿到的仍是稳定版。C7 迁移仪式在正式版之前就在真实数据上跑过。
  • ④ 创业阶段不扩散:三个选项都不新增发版流程。预发布模式(changeset pre enter next)走的是同一个 release.yml 和同一道人工批准,符合「不建议再建立一套 npm 发布流程」。

Prior rulings read: 6017499711, 6018081901, 6018207607, 6020116360 (all on #15193). Thread: #15193, newest 6020239413; nothing newer at this write. ⛔ No ruling has answered when to open, or how v18 ships after opening. That is what this card asks.

一句话问题

开 v18 之前,要不要先把 main 上现有的修复作为最后一个 17.x 发出去(不再等 #21908 的拒绝)?开线后,v18 是否用预发布模式分阶段发,直到迁移就绪再发正式版?

事实(read at this write)

选项 × 代价

选项 做什么 代价
A 先诊断 cloud#2637;刷新 version PR,你合并并批准,发最后一个 17.x;开线(pre enter next,放开 no-major 门禁);按 ADR-0131 链分阶段发 18.0.0-next.N;C7 和 cloud#1979 就绪后发 18.0 正式版 多一次你的合并加批准;#21908 的拒绝不进 17.x,只进 18.0(它是纵深防御的最后一层,生产方的显式授权在第 1 和 2a 阶段已经修好)
B 不发 17.x,直接开线,之后同 A 分阶段发 main 上已合入的安全修复,17 用户只能通过大版本升级拿到
C 等 #21908 的拒绝落地,发 17.x,再开线 开线时间取决于第 2a 阶段和拒绝什么时候落地

推荐 + 回退 + 置信缺口

  • 推荐 A。 你的方向(直接开 v18、分阶段发)不变,只在开线前加一次零成本的 17.x 收尾。
  • 两年后的样子: 17.x 停在一个包含所有已知安全修复的收尾版本上;18 的破坏性迁移经过 next 预发布实测后,只在正式版里发一次。
  • 回退 B。
  • 置信缺口: 不知道有多少外部用户自托管 17.x;cloud#2637 的根因未知。
  • 只看①选 A;②③④ 是否翻转:否。

裁后执行(A)

  1. cloud#2637: the cloud seat reports framework-caused or not. If it is framework-caused, its fix rides the 17.x.
  2. The release: the domain:devx seat triggers refresh_version_pr. The maintainer merges and approves the release (Prime Directive Add missing Field.phone() helper and factory methods for Action/Dashboard/Report #15).
  3. The opening:
  4. v18 stages: each 18.0.0-next.N is cut as the ADR-0131 chain completes a stage. The maintainer approves each, as with any release. 18.0 GA comes after C7 and cloud#1979.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:devpathThe road — create, dev, verify, publish/install, connect an agent, iteratedomain:devxpriority:p1High: required for production / M2target:v18

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions