Thunderbolt发布流程指南：版本号、changelog到上架的完整工作流

Thunderbolt发布流程指南版本号、changelog到上架的完整工作流【免费下载链接】thunderboltAI You Control: Choose your models. Own your data. Eliminate vendor lock-in.项目地址: https://gitcode.com/GitHub_Trending/thund/thunderboltThunderbolt 是一款让用户自由选择模型、拥有自己数据、摆脱供应商锁定的开源 AI 助手覆盖桌面Linux / macOS / Windows、iOS 和 Android 全平台。本文将带你完整走一遍它的发布流程从版本号管理、changelog 自动生成到一键构建上架各应用商店的自动化工作流帮助你快速理解一个跨平台项目的发布是怎么运作的。发布全流程一览一次触发全平台发布Thunderbolt 的发布核心是 GitHub Actions 自动化流水线。你只需要触发一次剩下的事情由 release.yml 工作流全部完成✅ 更新核心版本文件package.json、Cargo.toml、tauri.conf.json并提交✅ 创建并推送版本标签如v1.2.3✅ 并行构建桌面Linux / macOS / Windows、iOS、Android 安装包✅ 生成带 changelog 的 Release 页面并上传全部产物✅ iOS 包上传 TestFlightAndroid 包上传 Play StoreInternal 测试轨道支持3 种触发方式新手推荐前两种方式一CI 工作流推荐—— 在仓库 Actions 页面手动运行或用命令行gh workflow run release.yml -f version_typeauto # 从提交记录自动判断版本类型 gh workflow run release.yml -f version1.2.3 # 或显式指定版本号方式二本地脚本适合先演练—— 仓库内置了 scripts/create-release.ts支持--dry-run预览变更、--push推送并触发 CIbun run scripts/create-release.ts --dry-run # 安全预览不做任何修改 bun run scripts/create-release.ts --version 1.2.3 --push方式三纯手动—— 手动改好 4 个版本文件、提交并推送v1.2.3标签标签推送后会自动触发构建。 本地优先的好处先在本地--dry-run检查、再打标签、确认后推送避免过早触发昂贵的 CI 构建。版本号管理4 个文件如何保持同步跨平台项目最容易踩的坑就是版本号文件不同步。Thunderbolt 的解法是以src-tauri/tauri.conf.json为唯一事实来源其余文件按策略自动更新文件更新方式用途package.json发布脚本自动前端/Node 版本cli/package.json发布脚本自动CLI 工具版本src-tauri/Cargo.toml发布脚本自动Rust 后端版本src-tauri/tauri.conf.json发布脚本自动Tauri 配置事实来源src-tauri/gen/apple/project.ymliOS 构建时写入iOS 版本不提交bundle.android.versionCode构建时计算Android 构建号不提交版本哲学版本文件里永远存放下一个要发布的版本。当你打上v1.2.3标签时所有文件里应该已经是1.2.3标签指向的版本与文件完全一致从根源上杜绝版本错乱。Android 的巧妙设计versionCode不手动维护而是按公式1000 git 提交数在构建时自动计算。它始终唯一且单调递增满足 Google Play 要求同一个提交永远算出同一个值可复现还避免了只为了改版本号而提交的 git 噪音。版本类型自动检测major、minor、patch 怎么定如果触发发布时不显式指定版本脚本会分析自上一个标签以来的所有提交按 scripts/create-release.ts 中的规则自动判定语义化版本类型major提交信息含BREAKING或!破坏性变更minor提交以feat/feature开头新功能patch其余情况修 bug、依赖升级、维护类工作changelog 自动生成从 PR 标题到更新说明Thunderbolt 的 CHANGELOG.md 完全由 git-cliff 基于提交记录自动生成核心靠两个约定1️⃣ PR 标题规范化合并采用 squash-mergePR 标题即成为 main 分支上的提交信息。lint-pr-title.yml 会强制校验标题格式不符合规范的 PR 无法合并。推荐 Conventional Commits 风格feat(THU-58): add changelog automation # 新功能 fix: remove invalid header on mobile # 修复 chore(deps): bump tauri-apps/api # 维护2️⃣ 提交分类与噪音过滤cliff.toml 定义了分组规则——feat归入 Features、fix归入 Fixes同时自动跳过bump version、依赖升级等噪音提交。最终 changelog 形如## [0.1.130] - 2026-09-10 ### Features - Bump GLM models (#1269) (8f7f546) ### Fixes - Sync CLI version in nightly releases (#1273) (57f127e) 这套写规范的 PR 标题 → 自动生成结构化 changelog的模式让每次发布的 Release 页面对用户来说始终清晰可读无需人工编辑。上架各商店发布后的最后一步构建完成后各平台产物自动分发桌面端Linux 产出.deb/.AppImage/.rpmmacOSIntel Apple Silicon产出.dmgWindowsx64 ARM64产出.msi/.exe全部上传到 Release 页面并附带 Tauri 签名供自动更新iOS.ipa包自动上传TestFlight测试者会收到通知Android.aab包自动上传Play Store Internal 轨道如果需要单独给某个平台发版例如只发 iOS 测试版可以只触发对应平台的工作流它会创建类似v1.2.3-ios-rc的 RC 标签不影响桌面端版本。常见问题与最佳实践⚠️版本不匹配报错如标签是 1.2.3 但 package.json 是 1.2.2使用辅助工作流create-version-tag.yml统一更新所有文件再打标签。⚠️改动工作流时永远不要直接推送到 main先在ci-前缀的测试分支上验证确认无误再合并。✅回滚删除远程标签 → 删除 GitHub Release →git revert版本提交三步完成。✅必配 Secrets桌面端需要 Tauri 签名密钥iOS 需要 Apple 证书、描述文件和 App Store Connect API 密钥清单详见 RELEASE.md。相关文件导航 想深入源码可 clone 仓库浏览git clone https://gitcode.com/GitHub_Trending/thund/thunderbolt关键文件如下完整发布文档RELEASE.mdchangelog 生成配置cliff.toml版本更新脚本scripts/create-release.ts发布工作流.github/workflows/release.yml变更日志CHANGELOG.md构建命令参考Makefile掌握这套规范提交 → 自动定版 → 生成 changelog → 多端构建上架的完整工作流你就能理解 Thunderbolt 如何在一次触发后把所有平台的新版本安全、可复现地送到用户手中。【免费下载链接】thunderboltAI You Control: Choose your models. Own your data. Eliminate vendor lock-in.项目地址: https://gitcode.com/GitHub_Trending/thund/thunderbolt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考