发布策略
本运行手册描述如何避免用户在过时的桌面安装程序上完成 OAuth（包括 Gmail），而规范流程是最新发布。
分发
- GitHub Releases 是桌面构建的主要来源
- Tauri 更新器端点应将用户指向当前发布产物
- 淘汰旧稳定产物：当放弃某个发布线时，删除或隐藏过时的安装程序资产，更新网站/CDN 下载链接，刷新更新器清单
OAuth 最低应用版本
生产 web 构建在构建时嵌入最低支持的应用 semver，以便 OAuth deep link 无法在弃用的二进制文件上完成。
| 变量 | 用途 |
|---|---|
VITE_MINIMUM_SUPPORTED_APP_VERSION | 桌面应用必须**≥**此版本才能完成 openhuman://oauth/success |
VITE_LATEST_APP_DOWNLOAD_URL | 可选；默认为 GitHub 最新发布。当门阻塞 OAuth 时打开 |
工作流：staging vs. production
两个一流的 GitHub Actions 工作流，按意图选择而非切换标志：
| 工作流 | 分支 | 升级 | 推送标签 | 并发组 |
|---|---|---|---|---|
release-staging.yml | main | 仅 patch | v<version>-staging | release-staging |
release-production.yml | main | patch/minor/major | v<version> | release-production |
切 staging 构建
- 通过
workflow_dispatch从main运行 Release (Staging) - 工作流在
main上升级patch，提交chore(staging): vX.Y.Z，推送分支，并在该提交处创建不可变vX.Y.Z-staging标签 - 构建矩阵从标签运行（而非 main HEAD），因此重新运行会重建字节相同的内容
晋升到 production
- 通过
workflow_dispatch从main运行 Release Production，release_source = staging_tag - 工作流剥离
-staging，在相同提交处创建v<version>，并从该标签运行生产构建矩阵
热修复
- 运行 Release Production，
release_source = main_head - 工作流在 main 上运行 legacy 升级和标签路径
标签策略和回滚
- 命名。Staging 标签使用 SemVer 预发布后缀
-staging，因此它们在匹配的生产标签之前排序 - 碰撞。两个工作流在目标标签已存在时快速失败
- 回滚（生产）。失败的构建矩阵触发
cleanup-failed-release，删除草稿 GitHub Release 和v<version>标签 - 回滚（staging）。失败的 staging 构建删除
v<version>-staging标签
发布检查清单
- 升级
app/package.json和app/src-tauri/tauri.conf.json - 设置
VITE_MINIMUM_SUPPORTED_APP_VERSION为新地板 - 删除、重定向或淘汰旧稳定安装程序和过时更新器条目
- 从 releases/latest 全新安装上冒烟测试 Gmail connect
- 完成手动冒烟检查清单，然后将其粘贴到发布 PR 描述中