AskaEth
e3ee20bdcd
清单挂 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
5.0 KiB
5.0 KiB
产物矩阵与版本来源（M145 拆自 packaging/README.md）
本文承载原 packaging/README.md 的 §1、§2，节号沿用原编号（全仓 packaging/README.md §N 这类引用照旧有效，
对照表在 packaging/README.md 的索引里）。内容一字未改、只搬家：本行以上是 M145 新增的导航说明，
以下逐行取自原文件。
1. 产物矩阵
| 槽位 | 本版发布 | 产物文件名 | 形态 | 归档内容 |
|---|---|---|---|---|
windows-x64 |
✅ 发布 | unlucky-launcher_<ver>_windows_x64.exe |
裸 exe（双击即用） | exe 单文件；三份合规文本作为并列 Release 资产 |
windows-arm64 |
❌ 不发布（构建照跑取证） | unlucky-launcher_<ver>_windows_arm64.exe |
裸 exe（同 x64 策略） | 同上；CI 仍在原生 windows-11-arm runner 上构建（M140 起不交叉），红了不挡 x64 发布（M142，见 §3） |
linux-x64 |
❌ 不构建（未验证） | unlucky-launcher_<ver>_linux_x64.tar.gz |
单二进制归档 | unlucky-launcher + LICENSE + NOTICE + README.md |
linux-arm64 |
❌ 不构建（未验证） | unlucky-launcher_<ver>_linux_arm64.tar.gz |
单二进制归档（原生 ARM64 runner 构建） | 同上 |
macos-arm64 |
❌ 不构建（未验证） | unlucky-launcher_<ver>_macos_arm64.tar.gz |
单二进制归档 | 同上 |
macos-x64 |
❌ 不构建（未验证） | unlucky-launcher_<ver>_macos_x64.tar.gz |
单二进制归档 | 同上 |
| 每槽位 | 随所属槽位 | ull_<ver>_<平台>_<架构>[.exe] |
裸 CLI 文件（独立资产，不进 tar.gz） | 零 UI 依赖的 ull 本体，进同一份 SHA256SUMS.txt |
| 全平台 | 仅已发布资产 | SHA256SUMS.txt |
校验清单 | 每行 <sha256>␠␠<文件名>（sha256sum -c 可直吃） |
| 全平台 | 仅已发布资产 | manifest.json |
更新清单（D50，见 README.md §13） |
渠道 + 版本 + 各平台产物（target/format/url/size/sha256）；生成器 make_manifest.py |
约定细节：
- 「不构建」= CI 默认根本不跑（M139）：那四档未验证，产物不给用户、构建配额也不花；要整表六槽位取证走
gh workflow run release.yml -f all_slots=true（§3）。发布白名单只有windows-x64（M142：arm64 照构建、不发布）。 - 产物命名：
<名字>_<版本号>_<平台>_<架构>，下划线分段、不带实现细节字样（不出现iced）；真相源是make_artifacts.py::asset_stem()。 - "单文件"指可执行文件本身零运行时依赖（无 WebView、无 JRE、无 sidecar、无 DLL 旁挂）；归档里的三份合规文本是许可义务、不是运行时依赖，Windows 因为"一个 exe 装不下文本"，
把
LICENSE/NOTICE/README.md作为 Release 的并列资产分发，条款同样随下载走。 - 归档解压后是一个顶层目录
unlucky-launcher_<ver>_<平台>_<架构>/，用户不会解压出一堆散文件。 ull是并列的裸资产，不塞进 tar.gz：headless 用户要的就是「下一个小文件直接跑」；归档里放 LICENSE/NOTICE/README.md 是许可义务，而这三份本来就作为并列 Release 资产分发，裸ull不缺条款。unlucky-launcher本体也认全部 CLI 子命令（M82），ull不是第二个界面，而是不链接图形栈的同一套命令（差异见 §4 与 §7.4），两者不是重复品。 M118：GUI 的构建产物名是unlucky-launcher-iced（crates/app已被 workspaceexclude，不再产出unlucky-launcher）；对外文件名仍是unlucky-launcher，改名在make_artifacts.py落盘时（LAUNCHER_BIN找产物 /LAUNCHER_ASSET定对外名），所以下载链接 /SHA256SUMS/ 本文矩阵不变。<ver>不带前导v（tag 是v0.2.1，文件名是0.2.1）——由脚本统一裁剪。- UNIX 归档内
mtime/uid/gid归零、权限固定（二进制 0755、文本 0644）， 同源构建的 sha256 不受打包时刻影响。 - 架构不靠猜：脚本打包前回读二进制的可执行文件头（PE 机器码 / ELF
e_machine/ Mach-Ocputype），与槽位声明的架构不符即失败——不会出现"名字是 arm64、内容还是 x64"的假产物。
2. 版本来源（唯一真相源）
版本号只有一个来源：Cargo.toml 的 [workspace.package] version。
<ver>由make_artifacts.py通过cargo metadata --no-deps读出（不是正则扒文件）， 任何一个 workspace member 版本不一致时直接失败。- 带 tag 构建时（CI）额外传
--version "$TAG"：脚本裁剪v后与Cargo.toml交叉校验， 不一致即失败——避免出现 tag 说 0.2.1、产物里写 0.2.0 的发布事故。 ull --version必报同一版本（脚本打包前跑一次冒烟ull --version断言版本串在其中）， 这是env!("CARGO_PKG_VERSION")的实际输出，不是估算。- 发布流程：先改
Cargo.toml版本 + 提交 →git tag v<ver>→ 推送 tag 触发流水线。