AskaEth
374e168334
packaging/README.md 也是 400 行整，且安装包与自动更新马上要动发布线。按主题分成 「索引 + 5 份承载文件」，每份 ≤124 行： - README.md 只留真相源声明、§1–§12 的索引表、§11、§12 - docs/artifacts-and-version.md：§1 产物矩阵 + §2 版本来源 - docs/build-and-ci.md：§3 怎么构建 - docs/runtime-deps.md：§4 运行时依赖 + §5 软渲染兜底 - docs/profiles-and-measurements.md：§6 构建档位 + §7 实测 - docs/compliance-support-boundaries.md：§8 合规 + §9 支持矩阵 + §10 已知边界 节号沿用原编号，所以全仓「packaging/README.md §N」式引用（根 README / README.zh-CN / make_artifacts.py / release-notes.md / ci-runtime-smoke.md / release*.yml 注释）都不用改。 搬家由脚本按原文件切片生成，逐行可查：旧 README 400 行全部出现在新位置，唯一改写的 旧行是 §12 清单里那两行（文件清单必须反映拆分后实况）。新增行 15 条：索引段、§3 的 M145 说明、§12 的 5 份新文件行。
4.8 KiB
4.8 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 可直吃） |
约定细节：
- 「不构建」= 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 触发流水线。