RustFS 版本号升级实战指南基于 rustfs-release-version-bump 技能完成 alpha/beta/stable 发布文件变更【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs导读RustFS 的每一次正式发版alpha/beta/rc/stable都要求在一组固定的发布文件中同步版本号并保证 Docker 标签、Helm Chart、RPM 规格、Nix flake 与 Cargo 工作区版本彼此一致。本指南以仓库内.agents/skills/rustfs-release-version-bump/SKILL.md为骨架系统讲解这套版本升级技能的使用前提、硬性发布策略、六步工作流、验证与交付方式并结合当前仓库源码中的真实版本状态1.0.0-rc.5给出可执行的检查命令与实现依据。读完本文你将能够独立完成一次 RustFS 发布版本的版本文件升级与验证并理解它与rustfs-release-publish发布流水线的边界。技能定位何时使用 rustfs-release-version-bump该技能定义在 .agents/skills/rustfs-release-version-bump/SKILL.md其描述明确它负责为精确的 RustFS alpha/beta/stable 目标版本准备版本文件与发布资产的升级并附带验证与可选的 commit/push/PR 交付。它有两种触发场景用户显式要求升级某个版本号由 rustfs-release-publish 发布流水线调用。一个关键边界是打发布 tag 不属于本技能范围那是rustfs-release-publish的职责。本技能只负责版本文件的编辑与验证提交、推送和创建 PR 仅当用户交付范围中包含这些步骤时才执行。技能的校验基线是 PR#2957所采用的发布模式。前置输入与硬性约束必需输入使用前必须明确两个输入否则技能要求在动手前先停下询问精确目标版本例如1.0.0-beta.4、1.0.0-rc.5。版本缺失或含糊如发个版时必须先澄清禁止猜测。交付范围delivery scope从对话中推导分为三档local仅本地编辑与验证git包含commit/pushGitHub包含commit/push/PR。当未指明时技能默认在本地完成编辑与验证不阻塞在交付方式的问题上。-preview版本必须拒绝技能有一条明确的红线任何包含-preview的目标版本都必须拒绝写入版本文件。preview 标识符仅存在于 tag 层面属于rustfs-release-publish的预览验证流水线永远不允许出现在Cargo.toml、Cargo.lock等版本文件中。若被要求写入 preview 版本应停下并引导走发布流水线而不是编辑文件。编辑前必读正式改动前技能要求先阅读根目录及就近路径的AGENTS.md仅在准备 PR 时才阅读 PR 模板同时确认当前分支状态与相对origin/main的差异。硬性发布策略Hard Release Policy技能把以下三条规则列为不可擅改的硬策略任何调整都必须显式确认规则内容仓库佐证Docker 文档标签使用version形式如rustfs/rustfs:1.0.0-beta.4不带v前缀README.md 与 README_ZH.md 中的示例均为rustfs/rustfs:1.0.0-rc.5无v前缀Helm Chart 版本映射beta.N - 0.N.0例如1.0.0-beta.3 - 0.3.0、1.0.0-beta.4 - 0.4.0helm/rustfs/Chart.yaml 当前version与appVersion同为1.0.0-rc.5rustfs.specReleaseRelease字段只使用预发布后缀如beta.4rustfs.spec 中%global prerelease rc.5、Version: 1.0.0、Release: rc.5这里可以看到当前仓库正处于1.0.0-rc.5阶段Cargo.toml的[workspace.package].version为1.0.0-rc.5Cargo.tomlflake.nix 中rustfs包的version 1.0.0-rc.5rustfs.spec 的 changelog 顶部也以1.0.0-rc.5结尾。升级时需把所有此类位置同步到目标版本。默认发布文件清单技能把以下文件视为每次版本升级的默认检查清单default checklist只有当前仓库发布流程明确不再需要时才允许剔除某项文件作用需改动位置当前仓库证据Cargo.toml工作区版本与内部 crate 依赖版本[workspace.package].version第 76 行与[workspace.dependencies]中全部rustfs-*内部依赖第 91 行起均以1.0.0-rc.5声明Cargo.lock锁定的包版本需使工作区包版本与目标版本一致README.md英文文档中的版本化 Docker 示例第 144 行的rustfs/rustfs:1.0.0-rc.5README_ZH.md中文文档中的版本化 Docker 示例第 124 行的rustfs/rustfs:1.0.0-rc.5flake.nixNix flake 包版本第 80 行version 1.0.0-rc.5helm/rustfs/Chart.yamlHelm Chart 版本第 5-6 行version与appVersionrustfs.specRPM 打包规格第 3-6 行prerelease/Release与第 60 行起的 changelog从源码结构看Cargo.toml是一个大型 Cargo workspacemembers中包含rustfs主程序与 40 个crates/*子 crate因此内部依赖版本分散在[workspace.dependencies]中升级时需要对所有rustfs-*内部 crate 的version字段统一更新这正是re-scan for partial leftovers重新扫描残留遗漏这一步的意义所在。六步工作流详解步骤 1确认意图并隔离范围使用已提供的精确目标版本与交付范围仅在目标缺失、含糊或涉及重大发布策略选择时才提问。检查当前分支git status --short --branch确保本次任务只触碰与发布相关的文件不得混入无关的工作区改动。步骤 2更新工作区版本这是版本升级的核心包含四件事升级[workspace.package].version在 Cargo.toml 中把版本改为目标版本升级内部工作区 crate 依赖版本把[workspace.dependencies]中所有rustfs-*内部依赖如rustfs-audit、rustfs-ecstore、rustfs-iam等的version同步到目标版本更新Cargo.lock让其中工作区包版本与目标版本一致重新扫描残留用正则检查是否还有遗漏的旧版本号。步骤 3更新发布资产按文件逐一同步README 与 README_ZH把文档中版本化的 Docker 示例更新为目标版本。例如 README.md 中的# Using specific version docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:1.0.0-rc.5升级时把1.0.0-rc.5替换为目标版本注意不带v前缀见硬策略。flake.nix把 flake.nix 中rustfs rustPlatform.buildRustPackage { pname rustfs; version 1.0.0-rc.5; ... }的version字段更新为目标版本。helm/rustfs/Chart.yaml两个字段都要改helm/rustfs/Chart.yamlappVersion 目标版本version遵循 Chart 映射规则例如1.0.0-beta.3 - 0.3.0、1.0.0-beta.4 - 0.4.0。rustfs.specrustfs.spec把%global prerelease与Release设置为预发布后缀如beta.4在%changelog顶部新增/更新一条条目格式必须精确为* Thu May 20 2026 houseme housemecngmail.com - Update RPM package to RustFS 1.0.0-beta.4其中身份与时间必须取自当前环境而非照抄历史条目git config --get user.name git config --get user.email date %a %b %d %Ychangelog 中的版本文本必须与目标发布版本完全一致。仓库现有 changelog如第 60-62 行* Mon Aug 31 2026 overtrue anzhengchaogmail.com / - Update RPM package to RustFS 1.0.0-rc.5就是这种格式的直接示例。步骤 4发布前验证运行make pre-commit。根据 Makefile 的定义该目标是一个快速门禁make pre-commit # Fast gate: fmt-check guard scripts quick-check (NO clippy, NO tests)即包含fmt-check、guard 脚本与快速编译检查不跑 clippy 和测试。如果失败只修复本次任务可归因的失败项并重跑相关检查对于必须通过但无法解决的检查如实报告为BLOCKED不得静默扩大范围去修无关问题。步骤 5提交策略仅在获得授权时当Cargo.toml与Cargo.lock和文档/打包文件都发生变化时推荐拆分两次提交chore(release): prepare version—— 针对Cargo.toml与Cargo.lockchore(release): align release assets for version—— 针对文档与打包文件。如果用户要求单个提交则合并为一个。无论哪种方式都只暂存本次发布相关文件不得把工作区其他无关改动混入。步骤 6推送与 PR仅限授权的交付范围推送首次推送使用git push -u push-remote branch已配置跟踪后直接git push创建 PR 使用gh pr create --base main --head branch --title ... --body-file ...PR 模板的标题分区保持原样不适用部分填N/A并在正文中包含验证命令与任何BLOCKED原因PR 标题与正文必须使用英文。推荐检查命令速查技能给出了发布前自查的命令集合# 1. 查看当前分支状态 git status --short --branch # 2. 对比与 origin/main 的差异文件 git diff --name-only origin/main...HEAD git diff --stat origin/main...HEAD # 3. 扫描版本文件中的新旧版本残留核心检查 rg -n old_version|new_version Cargo.toml Cargo.lock README.md README_ZH.md flake.nix helm/rustfs/Chart.yaml rustfs.spec # 4. 发布前门禁 make pre-commit第 3 条是重新扫描残留的落地实现由于Cargo.toml的[workspace.dependencies]中所有内部 crate 都以同一版本声明用一次rg即可确认新旧版本号是否已被彻底替换。输出契约每次使用必须回报的内容技能强制要求每次使用后按固定契约汇报这也是自动化交付的可审计性保障目标版本Target version变更的文件Files changed需要确认的假设与不确定项验证结果PASSED或BLOCKED并附关键证据使用的提交信息Commit message(s)请求 GitHub 流程时的推送状态与 PR URL。与发布流水线的衔接版本文件升级与 tag 发布的边界本技能并非孤立的发版入口它与 rustfs-release-publish 形成完整流水线rustfs-release-publish编排整条发布流程在将版本文件升级到最终目标版本单一提交并合入阶段调用本技能此时携带已授权的 commit/push/PR 范围随后执行强制性的 preview-tag 验证循环最后才在同一个 commit 上打正式 tag 并发布。该流水线文档还揭示了版本信息来源最终二进制通过 shadow_rs 在构建时报告其 build tagbuild::TAGrustfs/src/config/cli.rs中的SHORT_VERSION也参与版本呈现而Cargo.toml仅提供无 tag 时的回退版本。这意味着Cargo.toml中的版本号是发布资产的无 tag 回退基准preview 与正式 tag 必须共享同一被验证的源码 commit——这正是本技能严格拒绝把-preview写入版本文件的底层原因preview 标识符只在 tag/Release 资产层面存在一旦混入版本文件就会破坏文件版本 交付版本的一致性约束。小结rustfs-release-version-bump技能把 RustFS 发版中最易出错、最繁琐的版本文件同步工作收敛为一套可重复、可验证、可审计的流程精确输入目标版本、守住-preview与 Docker/Helm/spec 三条硬策略、按 7 个默认文件逐项同步、以rg扫残留、用make pre-commit做门禁、按输出契约交付结果。对于维护者而言它保证了Cargo.toml、Cargo.lock、双语文档、flake.nix、Helm Chart 与 RPM 规格中所有版本号在每次 alpha/beta/stable 发版时严格一致也为后续rustfs-release-publish的 tag 发布提供了干净的基线 commit。【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考