chore(release): v2.2.3 —— 把 wheel 完整性清单修复送进可安装的产物 - #119
Merged
Merged
Conversation
准备发 2.2.3 时发现 #117 那份守卫有两处毛病，先改测试再动版本号： 1. 漏核一处：`scripts/installer/version.json` 是**安装器内嵌**的那份 （`setup.nsi:91 File "version.json"` 取的就是本目录里的文件），而仓库里没有任何脚本 重新生成它 —— makensis 是手工跑的。它现在停在 2.2.2/09-16 不动，装出来的壳就会拿一份 旧版本号做本地识别（那份代码自己的注释写着"缺失会静默跳过更新"）。加进核对清单， 站点数从 9 抬到 10（断言里的下限一起改，否则漏加会静默通过）。 2. 我自己写反的一条：`minimum_shell_version == 本次版本`。它的语义是**下界** （低于它的壳不接受了），强令相等等于每次发版顺手把上一版壳判死；而且目前代码里 没人真读它（`updater.rs` 只在 `AppVersion` 结构里解析，`shell-update.json` 扁平契约里 没这个字段），所以那条断言既没有依据、又会在未来逼出错误策略。改成唯一站得住的关系： 必须是 x.y.z 且**不高于**本次版本，比较走整数元组（字典序会把 2.9 判成比 2.10 大）。 15 passed（版本位 + 完整性打包两组）。 Signed-off-by: ReSerendipity <zengyangc@outlook.com>
v2.2.2 的 tag 指向 e64d0e6，而 #117 的修复晚于它 —— 也就是说**发布出去的 wheel 仍然缺 完整性自检三件套**：pip 安装方拿到的包，P0 保护照旧一条都不跑。这个补丁版就是为了把 修好的包交到人手里（发布流程见 docs/release-governance.md §2 第 3 步）。 版本位 11 处一起抬到 2.2.3（`.release-please-manifest.json` 必须同步，否则 main push 会被 #114 新加的自证步骤判"manifest 落后于最新 tag"而红）： pyproject / config.yaml / version.json / **scripts/installer/version.json**（安装器内嵌那份， 没有脚本会重新生成它）/ desktop 三处 + Cargo.lock / setup.nsi 三处 / k8s 镜像 tag。 `minimum_shell_version` 保持 2.2.2：它是下界，抬到 2.2.3 等于把刚发的一版壳判死。 CHANGELOG 新增 [2.2.3] 段：Security 一条（wheel 缺三件套 + enforce 静默跳过，含产物级验收数字 1062→1065）、Bug Fixes 两条（release-please 三处静默失效、版本位守卫补漏与撤掉一条写反的断言）， 并保留同 v2.2.2 口径的"已知未覆盖"三条（桌面安装器/分卷无 workflow、GPU 冒烟恒 skipped、 锁集真装待验）。 本次不重打 26 GB 便携分卷与增量包（未授权；这批不含权重变化）。 验证：`tests/test_version_consistency.py` 5 passed（10 处版本位一致 + OutFile/VIProductVersion 同源 + 下界不高于本次版本）、依赖/完整性守卫 28 passed 合计，三个 JSON 均可解析。 Signed-off-by: ReSerendipity <zengyangc@outlook.com>
上一条提交（09ea8e1）说"漏核 `scripts/installer/version.json`，因为没有脚本重新生成它"—— 前半句方向对、后半句是错的：它在 **.gitignore:436** 的"NSIS 安装器构建产物与装配中间物"清单里 （与 `TTSMultiModel.exe` 同批手工放进去），根本不是仓库跟踪的版本位。真版本源只有根 `version.json`。 按我上一提交那样硬性要求它存在，会在**干净检出/CI** 上直接 FileNotFoundError —— 本地跑得通只是因为那份装配中间物正好躺在工作树里。这类"只在开发机成立的红"最坑人。 改法：留住在场时的相等核对（装进安装器的那份一旦与源不同步，壳会拿旧版本号做本地识别， `assemble_installer_data.ps1:59` 自己写着"缺失会静默跳过更新"），缺席时不报错； 站点数下限从 10 回到 9（跟踪版本位的真实数量）。 三个情形都实跑过：中间物在场 → 5 passed；挪开模拟干净检出 → 5 passed； 把中间物改成 9.9.9 → 失败并点名 `scripts/installer/version.json（装配中间物） = 9.9.9`。 全量 2112 passed / 111 skipped / 0 failed。 Signed-off-by: ReSerendipity <zengyangc@outlook.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
为什么要有这一版
v2.2.2 的 wheel 里那个完整性保护缺口还在：修复（#117）合进 main 的时间点晚于 v2.2.2 的 tag
（
e64d0e6），所以已经发布出去的产物仍然缺integrity_manifest.json/ 其 Ed25519 签名 / 验签公钥，而
config.yaml默认enforce: true—— 从 PyPI 式安装拿到的包，P0 完整性自检照旧一条都不执行。这一版没有新功能，就是把修好的包交出去。（发布流程走
docs/release-governance.md§2 第 3 步：手工 tag + 手工 Release，因为 release-please 之前是结构性空转，修好后它自己开的 #115 会被本条取代。）
改动
pyproject.toml/config.yaml/version.json/ 桌面壳 3 处 +Cargo.lock/setup.nsi三处（OutFile、APP_VERSION、VIProductVersion）/deploy/kubernetes/deployment.yaml镜像 tag ×2 /.release-please-manifest.json（不同步的话 main push 会被 fix(ci): release-please 三处静默失效——它其实从没发过版（merge 需等 v2.2.2 tag 落地） #114 新加的自证步骤判"manifest 落后于最新 tag"而红）。
minimum_shell_version保持 2.2.2：它是下界，抬上去等于把刚发的那版壳判死。[2.2.3]：Security 一条（wheel 缺三件套 + enforce 静默跳过，带产物级数字1062→1065），Bug Fixes 两条（release-please 三处静默失效、版本位守卫的两处自我修正），
并保留"桌面安装器/分卷无 workflow、GPU 冒烟恒 skipped、锁集真装待验"三条未覆盖声明。
test_version_consistency.py）：① 撤掉我自己写反的
minimum_shell_version == 本次版本，改成"是 x.y.z 且不高于本次版本"（用整数元组比，字典序会把 2.9 判成大于 2.10）；
② 上一提交把
scripts/installer/version.json当成跟踪版本位硬要求存在 —— 它在.gitignore:436的"装配中间物"清单里，干净检出没有它，那条会在 CI 里 FileNotFoundError。改成若在场则必须等于源，站点下限回到 9。三个情形都实跑过：在场 5 passed /
挪开模拟干净检出 5 passed / 把它改成 9.9.9 → 红且点名。
验证
Integrity Manifest Sync Check16/16；三个 JSON 可解析；
scripts/check_spec_refs.py见下（本 PR 含 CHANGELOG 大量引用）。v2.2.3→python -m build出 wheel/sdist →twine check→ 解开 wheel 断言三件套在场（这才是这次发布的目的）→
SHA256SUMS.txt→gh release create→ 再从 Release 页面下载回来比对 SHA256。不含
26 GB 便携分卷与桌面增量包（未授权；本批不含权重变化）；GPG 资产分离签名（仓库无该 secret）。
Refs: #117（被本版携带的修复）、#114（发布自动化真修）、#115（本条取代它）