企业官网建设流程全解析

9 月 16 日装的 1.0.0，10 月 3 日 release 页冒出 1.0.1，同页每个平台还多挂了一个-latest.zip；另一条线上，每天北京时间 0 点 07 分 CI 会打出一个按日期命名的 nightly 包。跟版本号、跟 latest 别名、跟 nightly，三种跟法对应三种维护姿势。这篇把两条公开版本线各自的分工、升级风险和回退方式讲清，所有时间、文件名与链接都来自 release 页和 CI 配置的实测，结尾给一张决策表。

先交代 preview 的下落：GA 前后是两套节奏

动笔前把rustfs/rustfs的 tag 和 release 各翻了一遍（前 100 条），结论先说：现在公开可跟的版本线是两条，stable 和 nightly，preview 在 GA 之后公开渠道没有产物输出。

GA 之前的节奏是四级往下走：alpha 一路发到 99，beta 发到 12，每个大里程碑之间还夹着 preview 小步预发布，最后是 rc.1 到 rc.6。tag 命名直接能看到这个结构，比如1.0.0-beta.10-preview.1到1.0.0-beta.10-preview.5，是 beta.10 和 beta.11 之间的小步快跑；1.0.0-rc.6-preview.1是 rc.6 前的最后一小步。密的时候一天能出三个：beta.10-preview.2 和.3的创建时间都是 2026-07-16 09:39（UTC），.1在同一天早上 07:24。release 页上公开挂着的 preview 条目有 4 个（1.0.0-beta.10-preview.1到.3、1.0.0-rc.2-preview.1），全部标为 prerelease，也就是 GitHub 分类里的"预发布"，不会被releases/latest的规则选中。

GA 之后画风变了。9 月 16 日当天起，仓库陆续打出1.0.1-preview.1到1.0.1-preview.17共 17 个 tag，但这些 tag 在 release 页上查不到对应条目：公开 release 列表在 1.0.0 和 1.0.1 之间是空的，按 tag 直接查 release 返回 404。官方安装文档按部署形态分 SNSD、SNMD、MNMD 三种模式给建议，全文没有出现 preview 字样。

所以"stable、preview、nightly 三条线"的说法不成立，preview 是 GA 前的里程碑节奏，GA 后公开渠道的输出收敛到了两条线。范围交代一下：tag 和 release 各取前 100 条，release 侧已回溯到 3 月初的 alpha.84，更早的版本没有 preview 命名，结论不受影响。

stable 线：版本号是锚，latest 是个会动的别名

正式版目前两个：1.0.0（2026-09-16）和 1.0.1（2026-10-03），都在 GitHub Releases 上标为正式 release，间隔十七天。以 1.0.1 为例，附件一共 24 个：四个 Linux 平台（gnu/musl 两种 C 库 × x86_64/aarch64 两种架构）各带版本号 zip、deb、rpm，加 macOS、Windows 的 zip，再加每平台一个-latest.zip、SBOM、provenance 和两份校验和。

有个附件命名的变化顺手提醒：1.0.0 的 deb 还叫rustfs_1.0.0_amd64.deb，1.0.1 起改成了按平台命名的rustfs-linux-x86_64-gnu-v1.0.1.deb，rpm 同理。安装脚本里写死旧文件名的话，升级 1.0.1 前要把这行改掉。

-latest.zip不是另一个构建产物。构建流水线（build.yml）在出 release 包时，把版本化 zip 原样复制一份改名，两者字节相同，provenance 清单里 12 个产物的记录也能对上：同名平台的-latest.zip和带版本号的 zip 是同一个 sha256。

真正滚动的是下载 URL。GitHub 的通用规则releases/latest/download/<附件名>会 302 跳到最新正式版的同名附件，这个规则只认正式 release，prerelease 一律不参与，所以滚动链接不会被 rc 或 preview 这类预发布污染，1.0.0-rc.6 一直挂着的那些 prerelease 对它没有影响：

curl-LOhttps://github.com/rustfs/rustfs/releases/latest/download/rustfs-linux-x86_64-gnu-latest.zipcurl-LOhttps://github.com/rustfs/rustfs/releases/download/1.0.1/rustfs-linux-x86_64-gnu-v1.0.1.deb

两条路的分工就在这。开发机和 CI 想省事，用滚动链接一条命令装到最新正式版；生产集群固定版本号，升级窗口自己定。滚动链接的代价是 URL 背后的版本会漂：今天拿到 1.0.1，官方下次发版后同一个 URL 就是 1.0.2 了。文件名里的-latest也不会告诉你实际版本，装完跑一下rustfs --version，把版本号写进运维记录，别让"最新"两个字停在文件名上。

回退这件事在 stable 线上很省心。deb/rpm 的配置文件固定在/etc/default/rustfs（deb 打包时列为 conffiles，即 Debian 包里升级时受保护、不会被覆盖的配置文件），程序和数据目录各自独立，重装旧版本包就行，凭证和卷配置原样保留；用 zip 部署的更直接，换回旧 zip 就是回退。这也是固定版本号下载的另一个好处：旧包留在本地，回退时不用临时去找。

nightly 线：每天 00:07 构建一次，包名里带日期

nightly 的机制随 PR #7593（2026-09-09 合入）落地，标题写得很直白：把包发布为滚动nightlyrelease 的附件，而不是放在某个 git 分支里。随 1.0.1 发布后，用户侧才真正能看到这条线。

构建由 nightly-gnu.yml 负责，定时器是 cron7 0 * * *（Asia/Shanghai），也就是每天北京时间 0 点 07 分一次，流水线跑在官方自己的 runner 池（CI 执行机集群）上，构建步超时上限 150 分钟，产出 Linux x86_64 GNU 的 deb 和 rpm，命名rustfs-nightly-<日期>.deb/rustfs-nightly-<日期>.rpm。注意平台覆盖：nightly 目前只有 Linux x86_64 的 deb/rpm，ARM 或者用 zip 部署的环境，这条线覆盖不到。

两个值得留意的细节。一是构建来源：调度的 ref（构建所取的分支）跟随仓库变量NIGHTLY_BRANCH（未设置时回落到 main），workflow 注释说明 GA 周期可以把它指到release分支、之后切回main。平时跟 main，意味着今天合入 main 的修复，最迟第二天早上就能拿到包。另有一条 CI 改动（PR #7688）专门把 nightly 的各条 lane 绑定到同一个解析出的源码上，避免同一次 nightly 里混进不同来源的产物。二是包版本号：deb 版本写成YYYY.MM.DD~nightly这种日期快照格式（比如2026.10.11~nightly），rpm 是0-0.nightly.YYYY.MM.DD。workflow 注释解释了原因：dpkg 的版本号必须以数字开头、不能含连字符，纯nightly字样根本不合法；日期快照版本既满足格式，又能和正式版本号正常比较大小，包管理器做升级或回退时不会把这条线当成异常。文件日期也做了对齐，deb 的日期戳按 Asia/Shanghai 时区取值，和 cron 的时区一致，保证文件名里的日期就是构建当天。

发布去向有两路。公开的一路传到 Cloudflare R2，路径https://dl.rustfs.com/artifacts/rustfs/packages/nightly/，另有固定别名rustfs-nightly-latest.deb，实测返回 200，约 68.7 MB；流水线上传后会回读一次重算 sha256，对不上直接报错。R2 上还留了 run 级的候选存档，路径带构建的 run 编号、尝试次数和产物哈希（runs/<run_id>/<attempt>/<sha256>/rustfs.deb），加上 candidate 清单里记录的源码 commit，追溯某天的快照能一路落到具体文件和具体源码。另一路发到rustfs/auto-testing仓库的滚动 nightly release（PR #7593 的说明里称 rolling，即同一条 release 反复覆盖附件，不是每天新增条目），那个仓库是私有的（API 访问直接 404），workflow 注释里说明是给工程师直接下载安装用的，公开用户走的路径就是 dl.rustfs.com。

对 nightly 的定位，官方材料里能引用的表述只有机制描述：构建频率、来源分支、分发路径。workflow 里有按夜跑的测试 lane（比如 e2e-replication-nightly，复制链路的夜间端到端测试），注释也提到 nightly 链条的 gate 要求构建成功。但"跑过测试链"和"经过完整回归"是两回事，官方文档和 release 说明里都没有对 nightly 的稳定性承诺字样，这一层我按"机制有门禁、承诺无出处"来理解，建议你也这么算。

同一台测试机在两条线之间切换的操作也顺：装 nightly 快照就是一条dpkg -i rustfs-nightly-latest.deb（dpkg 是 Debian/Ubuntu 的包安装命令），版本号和正式版可比，不会报错；验证完想回正式版，因为快照版本号更大，得用--force-downgrade重装 1.0.1 的包。配置文件/etc/default/rustfs在两种包里都列为 conffiles，来回切换不会把凭证和卷配置冲掉，测完记得把环境记档就行。

跟 nightly 图什么，代价算在哪

nightly 的价值场景很窄也很明确：验证修复和提前踩新特性。完整走一遍是这样：给官方提了个 issue，讨论后修复合进 main，此时不必等下个正式版，第二天早上 cron 跑完，拉当天的快照到测试环境复现一遍，确认问题真关了，后面正式版一出就可以排升级窗口。想提前试某个新特性的也一样。日期命名还有个附带好处，复现问题时直接报"2026-10-11 的快照"，R2 上同一天的包是同一个文件，不歧义。

代价有三笔。第一，nightly 没有版本号语义，latest别名每天指向不同的东西，依赖它做自动化的人要接受环境每天在变；想复现某次测试结果，就得把当天的日期包存档，别依赖别名。第二，回 stable 不顺滑：按 dpkg 的版本比较规则，2026.10.11~nightly大于1.0.1，测试机想装回正式版时dpkg -i会把它当成降级拒绝，得加--force-downgrade。第三，上游对 nightly 没有支持口径，出了问题只能换快照或回正式版，没有"等补丁"这个选项。

生产集群跟 stable，nightly 只进测试环境。这是建议不是官方口径，但它基本是所有软件版本线的通用答案，RustFS 这里只是多了一个认真维护的 nightly 渠道可选。

决策表和动手时的三个动作

这张表划线的依据就两条：版本线有没有官方支持口径，产物的可追溯性能不能落到具体版本号。stable 两条都满足，nightly 满足第二条（日期快照 + run 级存档可溯源）但不满足第一条，所以它的边界画在测试环境。拿不准的时候按这两条对一遍，就能定下来。

动手时的动作固定三步：

sha256sum-cSHA256SUMS --ignore-missingsudodpkg-irustfs-linux-x86_64-gnu-v1.0.1.deb rustfs--version

升级前先在测试环境把 1.0.0 到 1.0.1 的路径过一遍再动生产，官方 CI 里就有专门的 e2e 升级链，说明升级路径本身是被测试覆盖的；旧包保留一份，回退就是重装旧版本包。nightly 的装完看一眼包版本号里的日期，知道自己跑的是哪天的快照；如果测试结果要留档，把按日期命名的快照包存进本地的制品库，别依赖latest别名，它明天指的就不是今天这个文件了。

安装与升级的更多细节见官方安装文档，所有版本的附件都在 RustFS Releases 页。