|
|
475aac867b
|
refactor(update): 内核与插件更新合并为 update 子系统（三端共享一个底层）
## 为什么合并（用户口径：更新部分应独立为子系统）
之前 kernelupgrade / pluginupdate 两个包，但它们共享三样东西，
分开写就要各复制一份，然后慢慢不一致：
① **版本比较** —— 合并前共 6 个函数做同一件事：
kernel 侧 ParseSemver / CmpSemver / versionNewer / trimTagV
plugin 侧 trimV / isNewer / semverNums（还自带一份正则）
且**行为不一致**：kernel 侧只挡 len<2，"1.4" 漏过去被填成 1.4.0；
plugin 侧的正则要求两段所以也漏。两份都把 "1.4" 当合法版本。
② **两阶段交互**（检查 → 确认 → 执行）—— 同一套用户口径。
③ **失败要响亮** —— 都不静默降级。
## 收敛结果
internal/update/
doc.go 子系统头：职责边界、三端共享契约、为何不分家
semver.go ParseSemver / CmpSemver / Newer / TrimTag（**唯一一份**）
kernel.go 内核升级闭环（解包→校验→备份→替换→重启→复核→回滚）
release.go GitHub Release 查询
plugin.go 插件升级（查仓库→拉源码→hmapdev 编译→产物）
三端共享：
agent 工具（plugin_update / kernel_update） ┐
WebAPI（/plugins/update、/kernel/update） ├─ internal/update
CLI（homed-upgrade） ┘
入口层只做参数解析与结果呈现，不含业务逻辑 —— 否则会出现
"agent 说没有新版、WebUI 却升了级"的分裂状态。
## 合并时抓到的两个真实 bug
① **ParseSemver 只挡 len<2** ⇒ "1.4" 被零值填成 1.4.0，
「1.4 → 1.4.0」被判完全相同（说"无需升级"），而两者内容未必相同。
现在要求恰好三段。
② **不认 v 前缀** ⇒ GitHub release tag 全是 v1.4.0 形态，
CLI 对"当前 v1.4.0 vs 包内 v1.4.0"判不可比、只能退回字符串比较。
现在 TrimTag 去 v 前缀后再比。
## 新增入口
· plugin_update（agent 工具）+ GET/POST /plugins/update
—— 两阶段：apply=false 只检查（列出 updatable / no_repo 两类，
后者是"未声明仓库、无法自动更新"的内置/私有插件）；
apply=true 需显式 plugins=all 或名单（不默认全升）
· kernel_update（agent 工具）+ GET/POST /kernel/update
—— 两阶段同构；apply 只收本机包路径（URL 下载是 CLI 职责，
agent 不该在推理中发起长下载）
判据：
· internal/update: Newer / TrimTag / ParseSemver 的边界（含上述两个 bug 的回归）
· pluginmgr 入口层 5 条：检查形状、apply 必须显式给范围、
kernel apply 必须给 pkg 且指向 homed-upgrade、拒绝目录当包
|
2026-10-26 01:05:09 +08:00 |
|
