mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-09-21 17:38:10 +00:00
8c6b593a54
三条此前没写进规范、于是被我在实际操作中做错的规则： ## 一、SDK 版本号跟随核心的中版本，patch 位恒为 .0（新 §七.1） 整条核心 1.1.x 线共用 SDK 1.1.0；只有核心进入 1.2.0 这种中版本跃迁时 SDK 才升。 核心的 patch 位专用于 bugfix 与漏洞修复，这类改动不碰公开 SDK 接口，SDK 版本号 没有理由跟着动。 **为什么不逐位对齐**：SDK 版本号是插件开发者的依赖声明。若核心每发一个 bugfix 就给 SDK 推一个新号，开发者要么被迫跟版、要么怀疑自己版本过时，而接口其实一个 字都没变。让 SDK 号只在**接口可能变化的中版本边界**上跳，开发者只需关心「我在 为哪个中版本写插件」。 因此「两仓版本对齐」在本规范里指**中版本对齐**（核心 1.1.x ↔ SDK 1.1.0）， 不是三位全等。核心 1.1.1 配 SDK 1.1.0 就是对齐状态。§四 的措辞同步修正。 ## 二、beta 阶段不发 SDK（新 §七.2） 核心的 alpha/beta tag 不伴随 SDK 仓发版：SDK 仓在这一阶段不打 tag、不建 release。 **为什么**：beta 是核心自己的测试阶段，此时 SDK 接口尚未固定。若此刻给 SDK 发版， 插件开发者会照着一个还会变的接口写代码——那是无效开发。接口没定就没有可依赖的 契约，发出去的版本号是一个假承诺。 这条约束的对象是 **SDK 仓的发版动作**，不是核心二进制里有没有 SDK 代码。主仓用 `replace => ./third_party/homeagent-sdk`，任何核心构建都必然含 vendored SDK 源码， 那是构建机制决定的，不在约束范围内。 核心打**正式** tag 时 SDK 才随之发版（§七.3）：SDK 仓也有自己的 `release/vX.Y.x`， 定版为 `X.Y.0`，打 tag、建 release、传 5 平台 plugindev 产物。同一中版本内的后续 核心 patch 不重复发 SDK。 ## 三、main 永远不是发版分支（补进 §四） 版本号 bump、打 tag、构建产物、上传附件，全部只在 `release/vX.Y.x` 上做。 **即使某个改动刚合进 main、即使 main 此刻可部署，也不从 main 打 tag。** main 的版本号是「下一个未发布中版本」的路牌，不是任何一次发布的版本号。 这条本该是 §2.1「main 的 meta.Version 始终是下一个未发布版本」的直接推论，但 只写了状态、没写禁令，于是留下了「main 可部署 ⇒ 可以从 main 发版」的误读空间。 §三 的分支表补上 main 现值 `1.2.0` 与 1.1.x 线的 tag 历史，让路牌语义有实例可对。 ## 四、公开接口改动是 feature，不是发布准备（补进 §六） 它必须走 `feature/xxx` → 合回 main → cherry-pick 到发布分支，不允许当成「发布 分支上的 bug 修复」直接提交进 release——发布分支冻结功能（§2.3），而接口是最 典型的功能面。§五 补上这条路径的命令示例，以及 SDK 仓同步发版的命令。