发布流程

本文说明 NodeGet 的发布工作流实际是怎么运作的：有哪几档发布，版本号怎么决定档位，手动发布时会发生什么。用户怎么安装这几档版本，见安装预发布版和 nightly。

三档发布

档位	版本号示例	怎么触发	构建的分支	说明
nightly	nightly	自动，每天一次	dev	滚动更新，不需要人操作
预发布	v0.7.0-beta.1、v0.7.0-rc.1	手动运行 release 工作流	运行时选择的分支	beta 功能可能还在变化，rc 已冻结功能、只修阻塞问题
正式版	v0.7.0	手动运行 release 工作流	运行时选择的分支	面向所有用户，默认安装的就是这一档

版本号决定发布的档位

release 工作流读取根目录 Cargo.toml 中 [workspace.package] 的 version，加上 v 前缀作为这次发布的版本号。版本号带 - 后缀（如 -beta.1、-rc.1）就是预发布，不带就是正式版。

	预发布	正式版
GitHub Release	标记为 Pre-release，不会成为 Latest	标记为 Latest
Docker 镜像	只推送对应版本的标签（如 v0.7.0-rc.1）	推送版本标签，同时更新 latest

所以发布预发布不会影响只装正式版的用户：安装脚本和 Docker 的 latest 都不会指向它。

版本号的格式是 v 加数字版本，可以带 - 或 + 后缀；不符合这个格式，发布时工作流会报错并停止。

版本号的大小关系按语义化版本比较：0.7.0-beta.1 < 0.7.0-rc.1 < 0.7.0。

release 工作流做什么

在 GitHub 的 Actions 页面选择 release，点 Run workflow。

• 只能手动运行。推送 tag 不会触发它。
• Use workflow from 选哪个分支，就构建那个分支的最新提交；Release 的 tag 也指向这个提交，由工作流在创建 Release 时生成。
• 发布选项 "Create/update the GitHub Release and Docker image"：
  • 不勾选：只做全平台构建，不创建 Release，也不推送镜像。
  • 勾选：构建完成后创建 GitHub Release，上传所有平台的文件，并推送 Docker 镜像。

发布日志

创建 Release 时，GitHub 会自动生成发布日志：列出上一个版本之后合并的 PR（标题、作者、编号），末尾附上和上一个版本的对比链接。日志内容取自 PR 标题，所以 PR 标题要写清楚改了什么。

上一个版本由 GitHub 按提交历史自动判断：发正式版时是上一个正式版，不把预发布算进去。这意味着发版时 Use workflow from 要选 main。上一个版本的 tag 在 main 的历史里，起点才是对的；如果从 dev 发，dev 的历史里没有这个 tag，GitHub 会往更早的版本找起点，日志里会列出大量早已发布过的 PR。

用户升级时的版本规则

• 主控和被控升级时，只能升级到正式版，目标版本号必须是纯数字（v0.7.0）。
• 升级到某个正式版时，正常是比较数字部分，不同才升级。当前运行的是 nightly 或预发布（版本号带后缀）时，即使数字部分和目标相同也会升级。比如运行 0.7.0-rc.1 的节点，可以升级到 0.7.0。
• 允许降级。

nightly

nightly 不需要人操作：

• 每天北京时间 02:00 自动从 dev 构建，覆盖全部平台。
• 如果 dev 自上次 nightly 以来没有新提交，当天会跳过。
• 构建出的版本号是当前版本号加日期后缀，如 0.7.0-nightly.20261011。
• 它滚动更新名为 nightly 的预发布，并推送 Docker 的 nightly 标签，不会影响 latest。
• 发布日志每次构建都会重新生成并覆盖：固定说明在前，后面列出自最新正式版以来合并的 PR。发了新的正式版之后，列表会从头开始。
• Release 的名称带构建日期，如 NodeGet Nightly 2026-10-12，和版本号里的日期后缀一致。
• 每天更新的是同一个 Release，而 GitHub 的"发布时间"只在发布时记录一次。所以每次构建完成后，工作流会把这个 Release 先切成草稿再立刻发布回来，让页面上的发布时间刷新为本次构建的时间。tag 和文件不受影响，草稿期间只有几秒钟按 tag 查不到这个 Release。

也可以在 Actions 页面手动运行 nightly，立刻构建一次。