 AskaEth
|
06fe12d811
|
chore(release): M154 版本升到 0.2.2（第一个稳定通道版本，D51）
- 根 Cargo.toml `[workspace.package] version` 0.2.1 → 0.2.2；`crates/{agent,app-iced,cli,palette-extract,
presenter}` 里 9 处 intra-workspace path 依赖的 version 约束一并对齐（M137 既定做法）。`crates/app` 是
workspace `exclude` 的 Slint 退役树，manifest 不参与解析，原样保留。
- Cargo.lock 由 cargo 再生成：只有 8 个 `unlucky-*` 成员条目从 0.2.1 变 0.2.2，第三方依赖（含版本号恰好
也是 0.2.1 的 hexf-parse / windows-link / windows-threading / xkeysym / yazi）一字未动。这一步不是可选：
CI 与发布流水线全走 `--locked`（ci.yml:236,274 / release-build.yml:135,142 / make_artifacts.py:50），
lock 不跟就是「tag 一打就红」。
- packaging 文档里的**示例 tag** 跟到 v0.2.2：docs/artifacts-and-version.md 两处（命名规则示例 + 「tag 说
X、产物里写 Y」的事故示例）、docs/build-and-ci.md 三处（`--version v…`、两次 `gh workflow run --ref v…`）、
docs/profiles-and-measurements.md 的「同一槽位现在叫 `unlucky-launcher_0.2.2_windows_x64.exe`」、
make_manifest.py 四处（Usage 示例 / `normalize_version` docstring / `--version` 的 argparse help）。
- **历史注记一律不动**：docs/runtime-deps.md 的「v0.2.1 首次真跑即红在工具链体检」（M140 事故记录）、
`.github/workflows/release.yml:71` 同一事故的另一处记录、`crates/core` 更新模块测试里的样本版本串
（`checker_cases.rs` / `version_cases.rs`，是解析器测试夹具，不是发布事实）、`microsoft.rs:224` 的
`21.0.13.0.2.1` 负例。
- README.md / README.zh-CN.md、packaging/release-notes.md 核实后**无需改动**：三份文件里没有任何写死的
版本号——下载表是 `<version>` / `<版本>` 占位符（M153 刚统一的口径，含非发布档位标「暂未发布」的行，
原样保留未回退），release-notes 正文是 `{{VERSION}}` / `{{SUMS}}` 模板占位符。
验证：`cargo check -p unlucky-cli --all-targets --locked` 过（编译日志里 unlucky-core/agent/cli 均报 v0.2.2）、
`cargo test -p unlucky-cli --lib --locked` 42 passed 0 failed、`cargo metadata --locked --offline` 过（全
workspace manifest + lock 一致）、`python3 packaging/make_manifest.py --self-test` ok、
`ull --version` 实跑输出 `ull 0.2.2（unlucky-cli）`。
|
2026-11-07 08:13:29 +08:00 |
|
|
AskaEth
|
e3ee20bdcd
|
feat(packaging): M151 发布流水线生成更新清单 manifest.json（D50）
清单挂 GitHub Release 资产，固定文件名 manifest.json（D50）。字段形状的权威是 M146 的
crates/core/src/update/manifest.rs（ReleaseManifest，deny_unknown_fields + 逐字段校验），
生成器只负责把那套形状填对，不另立 schema。
同源，不双写：packaging/make_manifest.py 的每个 sha256 直接读 Release 自己的
SHA256SUMS.txt，size 取自同一批文件的 stat()；产物名里的版本段必须等于 --version，
tag 与 Cargo.toml 漂了就没有产物可对，当场失败。CI 在「裁剪发布白名单后重算
SHA256SUMS」之后调它，所以清单描述的是真正要发的资产，不是构建出来的全部。
make_artifacts.py 只加 --manifest 开关，用子进程调同一份脚本（本地跑也产出
manifest.json），本文件继续是产物命名的唯一真相源。
只放启动器产物：DTO 的 Artifact 没有角色字段，Release::artifact_for() 取第一个
target 命中的产物，把 ull 并列写进去会让「覆盖哪个文件」取决于数组顺序；ull 照旧进
SHA256SUMS.txt 与 Release。
url 两种形态：默认裸文件名（DirSource 口径，本地/内网用）；CI 传 --asset-base-url
拼绝对地址并钉 tag（不是 latest），清单里每条都指向与它自报版本相符的字节。
自验：--self-test 用 packaging/tests/manifest.golden.json 逐字节对拍（覆盖裸 exe 与
tar.gz 两种形态，并钉住「ull 不进清单」），再跑 14 条负例证明严格解析不是摆设；
发布步会先跑它再产文件。真 DTO 对拍已在本机用 M146 的 ReleaseManifest 实测：
golden 解析通过（2 个产物、min_supported、force 均正确落位），14 条篡改全部被拒。
未决（报告带利弊，未自行改发布默认值）：releases/latest/download/* 只指向非 prerelease
的最新 Release，而发布默认 prerelease=true。
Refs: D50, M146
|
2026-11-06 22:15:58 +08:00 |
|