企业官网建设流程全解析

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

【免费下载链接】thunderboltAI You Control: Choose your models. Own your data. Eliminate vendor lock-in.项目地址: https://gitcode.com/GitHub_Trending/thund/thunderbolt

Thunderbolt 是一款让用户自由选择模型、拥有自己数据、摆脱供应商锁定的开源 AI 助手，覆盖桌面（Linux / macOS / Windows）、iOS 和 Android 全平台。本文将带你完整走一遍它的发布流程：从版本号管理、changelog 自动生成，到一键构建上架各应用商店的自动化工作流，帮助你快速理解一个跨平台项目的发布是怎么运作的。

发布全流程一览：一次触发，全平台发布

Thunderbolt 的发布核心是 GitHub Actions 自动化流水线。你只需要触发一次，剩下的事情由 release.yml 工作流全部完成：

1. ✅ 更新核心版本文件（package.json、Cargo.toml、tauri.conf.json）并提交
2. ✅ 创建并推送版本标签（如v1.2.3）
3. ✅ 并行构建桌面（Linux / macOS / Windows）、iOS、Android 安装包
4. ✅ 生成带 changelog 的 Release 页面，并上传全部产物
5. ✅ iOS 包上传 TestFlight，Android 包上传 Play Store（Internal 测试轨道）

支持3 种触发方式，新手推荐前两种：

方式一：CI 工作流（推荐）—— 在仓库 Actions 页面手动运行，或用命令行：

gh workflow run release.yml -f version_type=auto # 从提交记录自动判断版本类型 gh workflow run release.yml -f version=1.2.3 # 或显式指定版本号

方式二：本地脚本（适合先演练）—— 仓库内置了 scripts/create-release.ts，支持--dry-run预览变更、--push推送并触发 CI：

bun 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为唯一事实来源，其余文件按策略自动更新：

📌版本哲学：版本文件里永远存放"下一个要发布的版本"。当你打上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-merge，PR 标题即成为 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/.rpm，macOS（Intel + Apple Silicon）产出.dmg，Windows（x64 + 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.md
• changelog 生成配置：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