a5cf2c5f36
代码早就全量迁到 v3(go.mod 只要 wails/v3、main.go import v3/pkg/application), 但"怎么构建"这一层从没跟上,全还是 v2: - release.yml 装 v2 CLI(wails@v2.12.0)去编 v3 代码,编不过;产物路径也还 指向 v2 的 build/bin/,而 v3 落在 bin/。这条只在打 v* tag 时触发,迁移后 一次都没跑过,所以坏了半个月没人知道 —— 下次发版必炸。 - Makefile 的 wails dev/build 直接 command not found。 - README 叫人装 v2 CLI;RELEASE.md 还在提早已删除的 wails.json。 改动: - ci.yml 触发从 [main, dev] 收到 [main]。dev 分支已删,开发在 feat/wails3, 留着 dev 是死条件;PR 以 main 为目标仍会跑,合入前有关卡。 - release.yml 全量转 v3: * CLI 钉死 v3.0.0-alpha2.117,与 go.mod 的 wails/v3 版本一致 —— alpha 阶段 CLI 生成的 bindings 和运行时配套,版本错开会出难查的怪问题。 * mac 走 wails3 task darwin:package:universal。v3 的 build 只出裸二进制 (macOS 上双击不起窗),必须 package 才有 .app;本地实跑验证过, lipo -archs 确认是真 universal(x86_64 + arm64)。 * Windows 保持 v2 时代行为发裸 .exe。v3 的 package 默认走 NSIS 出 installer, 依赖 runner 上有 makensis,属额外未知数,要升级安装包再单独议。 * 产物路径 build/bin/ → bin/。 * fail_on_unmatched_files 改 true,并按 matrix 只匹配自己那个产物 —— 原来是 false 且两个平台都列全量文件,产物路径写错会安静发一个没附件的 Release。这次的 bug 正是路径漂移,得让它当场炸。 - RELEASE.md 版本号对齐表补上第三处 build/config.yml 的 info.version(此前写着 "必须三处对齐"却只列了两处,第三处是已删的 wails.json),并记下改完必须跑 wails3 task common:update:build-assets 重新生成 Info.plist —— 这坑踩过。 - 清掉 v2 残留:frontend/wailsjs/(v2 绑定,v3 用已跟踪的 bindings/)及其 gitignore 规则、build/bin/ 里 v2 时代的 .app。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.2 KiB
3.2 KiB
发版清单(桌面端 Release)
打 vX.Y.Z 标签即触发 .github/workflows/release.yml:
GitHub 用 macOS/Windows runner wails3 出包并发布到 Releases(mac 出 universal .app 的 zip、Windows 出 .exe);
旧版用户的 App 启动时查 releases/latest,发现新版即弹横幅提示下载
(逻辑见 version.ts)。
版本号一律用语义化
主.次.补(如0.1.1);git tag 带v前缀(v0.1.1),App 内不带。
一、发版前:改版本号(必须三处对齐)
| 文件 | 字段 | 作用 |
|---|---|---|
sundynix-desktop/frontend/src/lib/version.ts |
APP_VERSION |
功能性:App 拿它和 GitHub 最新版比,决定是否提示更新 |
sundynix-desktop/frontend/package.json |
version |
前端包版本(保持一致,便于追溯) |
sundynix-desktop/build/config.yml |
info.version |
原生包元数据版本(macOS Info.plist 的 CFBundleShortVersionString 由它生成) |
⚠️ 改完
build/config.yml必须跑wails3 task common:update:build-assets重新生成build/darwin/Info.plist等资产,光改 config.yml 不生效——生成物是提交进仓库的。 (这坑踩过:config.yml 填好了但没重新生成,.app里还是脚手架模板值,直接起不来。)
⚠️ APP_VERSION 必须等于即将打的 tag(去掉 v),否则更新提示会错乱:
新包内嵌的 APP_VERSION = 新版本;旧用户 App 内是旧版本,比对才会提示。
二、发版步骤
# 1. 改完上面三处版本号,提交
git add -A && git commit -m "release: v0.1.1"
# 2. 先 push 代码(release 从被打标签的提交构建;同时触发 CI 回归)
git push origin main # 或当前分支 dev
# 3. 打标签 + push 标签 → 触发 release 构建
git tag -a v0.1.1 -m "v0.1.1:<一句话变更>"
git push origin v0.1.1
三、验证
- GitHub → Actions → 看
Release工作流 macOS / Windows 两个 job 是否绿。 - GitHub → Releases → 确认
v0.1.1下有两个资产:sundynix_desktop_macos_universal.zipsundynix_desktop_windows_amd64.exe
- 用一台装了旧版的机器打开 App → 顶部应出现「新版本 v0.1.1 可用」横幅。
四、出错回滚 / 重发
# 删标签(本地 + 远程),改完重打
git tag -d v0.1.1
git push origin :refs/tags/v0.1.1
# 修复后重新执行「二、发版步骤」
五、注意事项
- 仓库需 public:Release 资产要让终端用户直接下载;private 仓库的资产下载需 token,不适合分发。
- 代码签名未做(待办):
- macOS 未公证 → 用户首次打开被 Gatekeeper 拦,需「右键 → 打开」或系统设置放行。正式分发需 Apple 开发者证书 +
notarize。 - Windows 未签名 → SmartScreen 警告。需代码签名证书。
- macOS 未公证 → 用户首次打开被 Gatekeeper 拦,需「右键 → 打开」或系统设置放行。正式分发需 Apple 开发者证书 +
- GitHub API 限流:更新检查未认证 60 次/小时/IP,按"每用户启动查一次"完全够用。
- CI(
ci.yml)在 push 到main/dev或 PR 时自动跑回归;Release 仅在 pushv*标签时触发。