9 月 16 日装的 1.0.010 月 3 日 release 页冒出 1.0.1同页每个平台还多挂了一个-latest.zip另一条线上每天北京时间 0 点 07 分 CI 会打出一个按日期命名的 nightly 包。跟版本号、跟 latest 别名、跟 nightly三种跟法对应三种维护姿势。这篇把两条公开版本线各自的分工、升级风险和回退方式讲清所有时间、文件名与链接都来自 release 页和 CI 配置的实测结尾给一张决策表。先交代 preview 的下落GA 前后是两套节奏动笔前把rustfs/rustfs的 tag 和 release 各翻了一遍前 100 条结论先说现在公开可跟的版本线是两条stable 和 nightlypreview 在 GA 之后公开渠道没有产物输出。GA 之前的节奏是四级往下走alpha 一路发到 99beta 发到 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:39UTC.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.02026-09-16和 1.0.12026-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.deb1.0.1 起改成了按平台命名的rustfs-linux-x86_64-gnu-v1.0.1.debrpm 同理。安装脚本里写死旧文件名的话升级 1.0.1 前要把这行改掉。-latest.zip不是另一个构建产物。构建流水线build.yml在出 release 包时把版本化 zip 原样复制一份改名两者字节相同provenance 清单里 12 个产物的记录也能对上同名平台的-latest.zip和带版本号的 zip 是同一个 sha256。真正滚动的是下载 URL。GitHub 的通用规则releases/latest/download/附件名会 302 跳到最新正式版的同名附件这个规则只认正式 releaseprerelease 一律不参与所以滚动链接不会被 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/rustfsdeb 打包时列为 conffiles即 Debian 包里升级时受保护、不会被覆盖的配置文件程序和数据目录各自独立重装旧版本包就行凭证和卷配置原样保留用 zip 部署的更直接换回旧 zip 就是回退。这也是固定版本号下载的另一个好处旧包留在本地回退时不用临时去找。nightly 线每天 00:07 构建一次包名里带日期nightly 的机制随 PR #75932026-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/rpmARM 或者用 zip 部署的环境这条线覆盖不到。两个值得留意的细节。一是构建来源调度的 ref构建所取的分支跟随仓库变量NIGHTLY_BRANCH未设置时回落到 mainworkflow 注释说明 GA 周期可以把它指到release分支、之后切回main。平时跟 main意味着今天合入 main 的修复最迟第二天早上就能拿到包。另有一条 CI 改动PR #7688专门把 nightly 的各条 lane 绑定到同一个解析出的源码上避免同一次 nightly 里混进不同来源的产物。二是包版本号deb 版本写成YYYY.MM.DD~nightly这种日期快照格式比如2026.10.11~nightlyrpm 是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 releasePR #7593 的说明里称 rolling即同一条 release 反复覆盖附件不是每天新增条目那个仓库是私有的API 访问直接 404workflow 注释里说明是给工程师直接下载安装用的公开用户走的路径就是 dl.rustfs.com。对 nightly 的定位官方材料里能引用的表述只有机制描述构建频率、来源分支、分发路径。workflow 里有按夜跑的测试 lane比如 e2e-replication-nightly复制链路的夜间端到端测试注释也提到 nightly 链条的 gate 要求构建成功。但跑过测试链和经过完整回归是两回事官方文档和 release 说明里都没有对 nightly 的稳定性承诺字样这一层我按机制有门禁、承诺无出处来理解建议你也这么算。同一台测试机在两条线之间切换的操作也顺装 nightly 快照就是一条dpkg -i rustfs-nightly-latest.debdpkg 是 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 没有支持口径出了问题只能换快照或回正式版没有等补丁这个选项。生产集群跟 stablenightly 只进测试环境。这是建议不是官方口径但它基本是所有软件版本线的通用答案RustFS 这里只是多了一个认真维护的 nightly 渠道可选。决策表和动手时的三个动作场景跟哪条拿货方式生产集群stable固定版本号releases/download/1.0.1/下按平台拿 deb / rpm / zip开发机、CI 脚本stable 的 latest 别名releases/latest/download/...-latest.zip滚动链接验证修复、提前试特性nightly仅测试环境dl.rustfs.com/artifacts/rustfs/packages/nightly/或rustfs-nightly-latest.deb生产nightly建议不跟nightly 目前只覆盖 Linux x86_64这张表划线的依据就两条版本线有没有官方支持口径产物的可追溯性能不能落到具体版本号。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 页。