RustFS 发版发布全流程实战从版本确认、Preview 预发布验证到最终 Tag 发布的完整指南【免费下载链接】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 开源仓库中沉淀的发布技能文档 .agents/skills/rustfs-release-publish/SKILL.md系统讲解 RustFS 从「确认目标版本」到「发布最终 Tag」的端到端发布流水线。该流水线以「Preview 预发布验证」为核心先在一个版本号上打-preview.N内部验证 Tag完成 CI 全矩阵构建、Release 资产校验、本地二进制与内嵌 Console 验收、最新 rc 客户端兼容性测试后停下来等待人工确认再在同一个 commit上打最终 Tag从而保证「代码零差异、产物可追溯」。读完本文你将掌握 RustFS 的 SemVer 选版规则、版本文件的一次性 bump 策略、Preview Tag 命名与 fail-closed 机制、Console 发布门禁、人工确认门禁以及最终发布与 Preview Release 清理的完整操作序列。一、流水线总览一次发布要经过哪七个环节RustFS 的发布流水线可以概括为下面这张「管线形状」原文 Pipeline shapecheck console main against its latest Release - if ahead: publish console - wait for Release asset latest API - bump RustFS version files to target (final version, ONE commit) - merge - tag preview-tag at that commit - CI green - verify preview Release assets - run binary locally console checks - validate with latest rc client - report preview acceptance results - STOP for explicit human confirmation - tag target at the SAME commit (zero delta) - re-verify CI/release - CI deletes the target-preview.N Releases (tags kept)七个阶段的核心意图是把「代码正确」与「版本号正式」彻底解耦。Preview Tag 与最终 Tag 共享同一个经过验证的源码 commit即PREVIEW_HASH二者仅 Tag 名称不同因此二进制内部自报的版本号与产物文件名不同版本号只在版本文件中写一次写最终target绝不写-preview.N后缀预览验证失败时修复走普通 PR 合入 main此时版本文件已是target无需再次 bump然后在新的 main commit 上打-preview.(N1)从 Phase 2 重新开始。该流水线由两个技能协同完成rustfs-release-publish本文主体负责编排与发布与rustfs-release-version-bump.agents/skills/rustfs-release-version-bump/SKILL.md负责版本文件修改与提交。发布技能在 Phase 1 以「commit/push/PR」授权范围调用版本 bump 技能。各阶段与本文小节对应关系阶段主题本文小节输入确认目标版本与 Preview 迭代号第二节SemVer 门禁版本号语义与选版规则第三节Phase 0预检 Console 发布门禁第五节Phase 1版本文件一次性 bump 到target第六节Phase 2发布 Preview Tag第七节Phase 3CI 与 Preview Release 验证第八节Phase 4–5本地二进制、Console、rc 验收第九节人工确认门禁显式确认后放行第十节Phase 6最终 Tag 发布与清理第十一节二、必需输入目标版本与 Preview 迭代号启动流水线前必须明确两个输入最终目标版本例如1.0.0-beta.10Preview 迭代号N默认取该目标下一个未使用的 preview Tag。查询方式先git fetch --tags再执行git tag -l target-preview.*如果目标版本缺失或含糊应当先收集当前 release/tag 基线再向用户询问确认不要直接动手改版本或发布。在等待答复期间可以继续执行只读的预检即下文 SemVer 门禁的只读部分。仓库现状佐证当前仓库Cargo.toml的 workspace 版本为1.0.0-rc.5helm/rustfs/Chart.yaml的version与appVersion均为1.0.0-rc.5rustfs.spec为Version: 1.0.0Release: rc.5——这正是「版本号只写在版本文件中、Tag 不含 v 前缀」的实际体现详见第六节。三、SemVer 门禁先定版本再谈发布RustFS 的版本遵循 SemVer 2.0.0仅作规范引用非仓库外链接广告。发布技能特别给出了优先级排序提醒1.0.0-alpha 1.0.0-alpha.1 1.0.0-beta.2 1.0.0-beta.11 1.0.0-rc.1 1.0.0 1.0.1 1.1.0 2.0.0关键语义点预发布标识符按数值比较beta.9 beta.10而非字典序——对应 semver.org spec item 11Preview Tag 是叠加在目标预发布通道之上的内部验证 Tag它本身永远不是交付版本也永远不会出现在版本文件中。选版规则硬性约束「发个版」这类请求永远被视为含糊。正确做法是先推导当前最新 Taggit tag --sort-v:refname | head再向用户提供具体候选。以1.0.0-beta.10为例候选可能是下一个预发布1.0.0-beta.11、晋升1.0.0-rc.1、晋升稳定版1.0.0。三者含义差异巨大通道晋升 vs 迭代号递增且在 CI 中有不同的分类后果绝不能替用户猜。已有稳定版X.Y.Z之后下一个版本必须明确哪个分量递增仅修复用 patchX.Y.(Z1)向后兼容新特性用 minorX.(Y1).0破坏性变更用 major(X1).0.0。若用户只给了 bump 类型没给数字则从最新稳定 Tag 计算并把精确版本号回显给用户确认。在首份状态报告中逐字回显最终确认的版本字符串后续每个阶段都必须使用完全相同的字符串一旦发现用户措辞与已确认版本不一致立即停下重新确认。从源码看版本语义在构建与运行期是自洽的rustfs/src/config/cli.rs中SHORT_VERSION取version::DISPLAY_VERSIONLONG_VERSION拼接build::TAGshadow_rs 在构建期嵌入的 Tag 名而命令行入口#[command(name rustfs, version SHORT_VERSION, long_version LONG_VERSION)]让./rustfs --version既能报告 Cargo 版本也能报告构建时打的 Tag——这正是「Preview 产物必须自报 Preview Tag」的底层机制。四、Preview Tag 命名与硬性规则Preview Tag 命名所有目标统一使用target-preview.N例如1.0.0-beta.10-preview.3或1.1.0-preview.1规范后缀必须精确为-preview.digits。build.yml在 alpha/beta/rc 分类之前识别它并路由到 preview-only 路径任何包含-preview但不符合该后缀的 Tag 会fail closed构建直接报错退出而不会被当作 release 处理。这段逻辑在 .github/workflows/build.yml 中有明确实现build-check任务先用正则-preview\.[0-9]$匹配合法 Preview Tag置build_typepreview、is_prereleasetrue再用*-preview*兜底匹配若含-preview却不满足规范后缀则输出❌ Invalid preview tag并以exit 1中止——这就是「fail closed」的源码证据。Preview Release 的三条硬性约束Preview Release 必须以isPrereleasetrue、isLatestfalse发布任何*-latest资产、或由 preview 触发的latest.json、R2、Docker、Helm 发布行为一律视为流水线故障Preview Release 由最终 Tag 发布成功后的cleanup-preview-releases任务清理它删除所有 Tag 精确等于target-preview.digits的 Release且从不传--cleanup-tag因此 Tag 本身得以保留。.github/workflows/build.yml 的cleanup-preview-releases任务正是该清理逻辑用gh release delete $preview_tag --repo ... --yes删除 Release并用 jq 精确匹配startswith($tag -preview.)且后缀为纯数字的 Tag 列表注释明确写着「Only the Releases are deleted; the -preview.N tags stay」。十项硬性规则速查版本文件Cargo.toml、Cargo.lock、README、flake.nix、Chart.yaml、rustfs.spec只 bump 一次、直接到target绝不写入-preview.N后缀若 bump 技能收到-preview版本请求属于流水线 bug立即停止。Preview Release 资产是带版本号、且在验证期间刻意在 Releases 页可见的不得标为 Latest不得用于更新任何 latest 分发通道。Phase 6 完成前绝不手工删除 Preview ReleasePhase 4 要下载其资产最终 Release notes 在它仍存在时生成清理是 CI 的职责只有cleanup-preview-releases失败时才手工介入gh release delete preview-tag --yes绝不加--cleanup-tag。Tag 不带v前缀必须打注记 Taggit tag -a tag -m Release tag。最终 Tag 必须精确指向PREVIEW_HASH即经验证的 Preview Tag 所在 commit绝不 tag 当前 main HEAD验证之后合入的 commit 未经验证也绝不在 preview 与 final 之间再造一个版本 bump commit。存在上一个交付版本时preview 与 final 的 Release notes 必须以它作为共同对比基线即目标之前最近一个非 preview 的已发布 Release内部-preview.NRelease 即使与最终 Tag 指向同一 commit 也显式排除因为清理在 notes 生成之后才执行否则 preview Release 会被误选为基线。若仓库没有任何历史交付版本则省略previous_tag_name并记录 GitHub 默认基线回退行为。生成的 Release notes 带有工作流管理标记供重试时修复手工润色生成内容前必须先移除该标记未带标记、非占位符的 notes 会被后续工作流运行保留。各阶段严格按序执行任一阶段失败都会阻塞其后所有阶段修复合入 main 后用新origin/mainhash 从 Phase 2 以-preview.(N1)重新开始绝不基于过期 hash 从中间恢复。完成 preview 验收不等于授权最终 TagPhase 3–5 通过后必须汇报验收证据并停止直到用户显式确认继续原始发布请求、早前确认、沉默或自动化跟进都不满足此门禁。确认的范围绑定在本次汇报的target、preview-tag、PREVIEW_HASH三元组上任何失败的验收循环或新的 preview 迭代都会使旧确认失效需要重新确认。沟通约定面向用户的状态更新用中文commit、PR 标题/正文、Tag 消息用英文commit 消息、PR 正文与文档中不手工换行每个句子/段落一行交给软换行处理显示。五、Phase 0 —— 预检与 Console 发布门禁基础预检git status --short # 工作区必须干净 git fetch origin main --tags gh auth status # GitHub CLI 已认证 gh release list -L 3 # 能查看最近的 Releases同时确认最终目标版本若用户未显式给出在 Phase 1 前确认清楚。Console 发布门禁发布技能要求在 Phase 1 之前完整执行 .agents/skills/rustfs-release-publish/references/console-gate.md 描述的 Console 门禁。原因是 RustFS 的build.yml会下载repos/rustfs/console/releases/latest返回的资产——一个成功的 Console 构建本身并不满足门禁必须存在已发布、资产完整的最新 Release。门禁共四步第 1 步对比最新 Console Release 与 Console mainCONSOLE_REPOrustfs/console CONSOLE_LATEST$(gh api repos/${CONSOLE_REPO}/releases/latest --jq .tag_name) gh api repos/${CONSOLE_REPO}/compare/${CONSOLE_LATEST}...main \ --jq {status, ahead_by, behind_by, commits: [.commits[] | {sha, message: .commit.message}]}ahead_by 0没有待发布的合并变更仍按第 4 步校验最新资产然后进入 Phase 1ahead_by 0且behind_by 0先发布 Console。汇报已合并的 commits选择下一个未使用的vX.Y.ZTag变更属于修复或向后兼容 UI 时默认取下一个 patch 版本若疑似 minor/major停下等确认历史出现分叉或behind_by 0停止显式厘清 Console 发布基线不要猜测范围也不要发布 RustFS。第 2 步克隆 Console 到临时目录并记录精确 commitCONSOLE_SCRATCH$(mktemp -d) gh repo clone $CONSOLE_REPO $CONSOLE_SCRATCH/console git -C $CONSOLE_SCRATCH/console fetch origin main --tags CONSOLE_HASH$(git -C $CONSOLE_SCRATCH/console rev-parse origin/main) git -C $CONSOLE_SCRATCH/console tag --points-at $CONSOLE_HASH v* gh run list -R $CONSOLE_REPO --workflow release.yml --commit $CONSOLE_HASH --limit 5若该 hash 上已存在v*Tag 或进行中的 Release 工作流等待它完成而不是再造一个版本否则在该 hash 上创建注记 Tag 并推送Console Tag 带v前缀推送触发.github/workflows/release.ymlgit -C $CONSOLE_SCRATCH/console tag -a console-tag -m Release console-tag $CONSOLE_HASH git -C $CONSOLE_SCRATCH/console push origin console-tag门禁完成后删除CONSOLE_SCRATCH。第 3 步找到精确的 Tag 运行并等待完成gh run list -R $CONSOLE_REPO --workflow release.yml --branch console-tag --limit 1 gh run watch -R $CONSOLE_REPO console-run-id --exit-status第 4 步阻塞式校验发布结果——Release 非 draft、latest 端点返回预期 Tag、资产rustfs-console-console-tag.zip已上传、非空且带sha256:摘要gh release view -R $CONSOLE_REPO console-tag --json isDraft,isPrerelease,assets,url test $(gh api repos/${CONSOLE_REPO}/releases/latest --jq .tag_name) console-tag test $(gh api repos/${CONSOLE_REPO}/releases/tags/console-tag \ --jq [.assets[] | select(.name rustfs-console-console-tag.zip and .state uploaded and .size 0 and (.digest | startswith(sha256:)))] | length) -eq 1资产缺失/摘要不匹配/latest Tag 不符/工作流失败或取消一律判为 BLOCKED。门禁通过前不得开始 Phase 1。最终报告中记录CONSOLE_TAG、CONSOLE_HASH、Console run URL 与 Release URL。六、Phase 1 —— 版本文件一次性 bump 到最终目标先检查如果 main 的版本文件已读作target例如这是失败后的重启场景用下式确认后直接跳到 Phase 2rg -n target Cargo.toml rustfs.spec helm/rustfs/Chart.yaml否则调用rustfs-release-version-bump技能传入最终target绝不是 preview 版本并采用完整 GitHub 流程commit/push/PR。该技能的默认版本文件清单为Cargo.tomlCargo.lockREADME.mdREADME_ZH.mdflake.nixhelm/rustfs/Chart.yamlrustfs.spec关键策略[workspace.package].version与内部 workspace crate 依赖版本一起 bumpCargo.lock同步并重新扫描残留的旧版本号helm/rustfs/Chart.yamlappVersion 目标版本version按映射规则转换如1.0.0-beta.3 - 0.3.0、1.0.0-beta.4 - 0.4.0rustfs.specRelease只写预发布后缀如beta.4并在 changelog 顶部按精确格式追加条目作者来自git config --get user.name/email日期来自date %a %b %d %Y提交建议拆分chore(release): prepare versionCargo 文件与chore(release): align release assets for version文档与打包文件只暂存发布相关文件不夹带无关改动交付前运行make pre-commit失败时修复本任务可归因的问题并重跑受影响检查无法解决的必需检查上报 BLOCKED。PR 合入 main 后记录结果 commitgit fetch origin main PREVIEW_HASH$(git rev-parse origin/main) # must contain the bump PRPREVIEW_HASH是整条流水线的唯一事实来源single source of truth——向用户汇报并在 Phase 2 与 Phase 6 逐字复用。preview 与 final 两个 Tag 都将指向它。仓库佐证当前仓库的版本文件正处于「预发布通道」状态1.0.0-rc.5与技能文档描述的流程完全一致——版本号仅存在于版本文件Tag 只负责触发 CI 分类。七、Phase 2 —— 发布 Preview Taggit tag -a preview-tag -m Release preview-tag $PREVIEW_HASH git push origin preview-tag推送 Tag 会触发 .github/workflows/build.yml工作流名 Build and Releasedocker.yml通过workflow_run事件链式触发。仓库中的 .github/workflows/docker.yml 明确给出了该链式条件仅当触发事件为push、head_branch ! main且不包含-preview时才发布镜像——这从源码层面印证了「Preview 运行必须跳过 latest 通道、R2、Docker、Helm 发布路径」。Preview 运行会构建带版本号的产物并发布为一个 GitHub prereleaselatest 通道、R2、Docker、Helm 任务必须被跳过这些发布路径只在最终 Tag 推送后执行。重启场景N1先刷新PREVIEW_HASH$(git rev-parse origin/main)必须包含修复并重新汇报。八、Phase 3 —— CI 与 Preview Release 验证找到并盯守 Tag 构建gh run list --workflow build.yml --branch preview-tag --limit 1 gh run watch run-id构建矩阵的每个目标都必须成功linux x86_64/aarch64 × musl/gnu、macos-aarch64、windows-x86_64。确认 Release 发布任务create-release、upload-release-assets、publish-release成功同时update-latest-version被跳过。校验 Preview Release 状态gh release view preview-tag --json isPrerelease,assets,url gh api repos/{owner}/{repo}/releases/latest --jq .tag_nameisPrerelease必须为trueRelease 必须包含全部 6 个带版本号的平台 zip、校验和、SBOM 与 provenance且没有任何-latest资产latest API 不得返回preview-tag。确定 Release notes 对比基线PREVIOUS_DELIVERABLE从已发布 Releases 中按publishedAt选择排除当前 Tag 与所有-preview.NTag。校验gh release view preview-tag --json body --jq .body含## Whats Changed且在存在PREVIOUS_DELIVERABLE时含**Full Changelog**: https://github.com/rustfs/rustfs/compare/PREVIOUS_DELIVERABLE...preview-tag无历史交付版本时确认存在 Full Changelog 链接并记录 GitHub 基线回退。确认 Preview 触发的 Docker/Helm 任务被跳过。原因Dockerfile 消费 GitHub Release 资产因此 Docker 镜像构建与 Helm 发布延迟到最终 Tag 才执行Preview 验证覆盖的是 RustFS 二进制、内嵌 Console 与 rc 兼容性。九、Phase 4–5 —— 本地二进制、Console 与 rc 验收详细操作见 .agents/skills/rustfs-release-publish/references/preview-acceptance.md以下是完整流程。Phase 4本地运行产物并验证 Console在会话 scratchpad 目录内工作绝不遗留散落的 data 目录gh release download preview-tag -p rustfs-macos-aarch64-vpreview-tag.zip -D $SCRATCH cd $SCRATCH unzip -o rustfs-*.zip ./rustfs --version # 必须报告 PREVIEW TAGbuild::TAG而非 Cargo.toml 版本且含预期短 SHA mkdir -p data RUSTFS_ACCESS_KEYrustfsadmin RUSTFS_SECRET_KEYrustfsadmin ./rustfs ./data默认端口S3 端点:9000内嵌 Console:9001。必须全部通过的检查项./rustfs --version报告 preview Tag 名与PREVIEW_HASH的短 SHA。若报告的是不带-preview.N后缀的target说明构建未嵌入 Tag——判 FAIL 并先调查再继续这正是rustfs/src/config/cli.rs中build::TAG的作用点curl -fsS http://localhost:9000/health/ready返回 ready启动日志显示内嵌 Console 被提供这正是fix(release): require embedded console assets这个回归修复所守护的场景浏览器打开http://localhost:9001用rustfsadmin/rustfsadmin登录dashboard 渲染无 JS 控制台错误创建 bucket、上传文件、回下载字节级一致、删除对象与 bucket。Phase 5 期间保持服务器运行。Phase 5用最新 rc 客户端验证rc是 RustFS 的 CLI 客户端。先确保已安装最新版rc --version与gh api repos/rustfs/cli/releases/latest --jq .tag_name对比必要时brew upgrade rustfs/tap/rc或下载 Release 二进制。随后指向 preview 服务器执行命令矩阵逐条记录 PASS/FAILrc alias set preview http://localhost:9000 rustfsadmin rustfsadmin rc ls preview/ rc mb preview/rel-check rc cp local-file preview/rel-check/ rc stat preview/rel-check/file rc cat preview/rel-check/file # 与源文件一致 rc cp preview/rel-check/file ./out cmp local-file ./out rc cp -r local-dir/ preview/rel-check/dir/ rc find preview/rel-check --name * rc share download preview/rel-check/file --expire 1h # 预签名 URL 可被 curl 拉取 rc rm preview/rel-check/file rc rm -r --force preview/rel-check/dir rc rb preview/rel-check rc admin user list preview/ rc admin user add preview/ relcheckuser relchecksecret12 rc admin user remove preview/ relcheckuser rc alias remove preview任何 FAIL 都会阻塞发布。全部通过后停止服务器并删除 scratch 数据目录。验收结果需保留供人工确认门禁使用。十、人工确认门禁发布前的最后一道闸Phase 3–5 全部通过后必须汇报以下证据并显式询问用户是否发布最终 Tag然后结束本轮不得创建或推送target目标版本、preview Tag、PREVIEW_HASHPreview Release URLConsole 验收结果rc 命令矩阵结果。只有用户在新的回复中显式确认所汇报的目标、preview Tag 与 commit 后才可进入 Phase 6。对本次汇报的明确肯定如「确认继续」即满足若回复含糊或汇报中的任一值发生变化需再次询问。设计意图硬性规则 9/10完成 preview 验收不等于授权最终 Tag原始发布请求、早前确认、沉默或自动化跟进都不满足该门禁确认与具体的target/preview-tag/PREVIEW_HASH三元组绑定失败的验收循环或任何新的 preview 迭代都会使旧确认失效。十一、Phase 6 —— 在验证过的 commit 上发布最终 Tag没有第二次版本 bump没有发布分支。最终 Tag 精确打在 preview 验证过的 commit 上git fetch origin --tags git rev-parse preview-tag^{commit} # 必须等于 PREVIEW_HASH——不等则中止 git tag -a target -m Release target $PREVIEW_HASH git push origin target随后执行完整发布验证CI 全链路CI 从同一源码重建唯一变化是 Tag 名因此二进制现在自报target构建矩阵与全部 release 任务必须 green。Release 资产gh release view target显示完整的有版本号资产集 -latest资产集外加校验和、SBOM、provenanceDocker 与 Helm 工作流成功latest.json指向target。稳定版必须isPrereleasefalse、isLatesttruealpha/beta/rc必须isPrereleasetrueGitHub 不允许预发布被标为 Latest但项目的latest.json仍推进到最终的 non-preview 目标。Release notes正文含## Whats Changed与 Full Changelog 链接存在PREVIOUS_DELIVERABLE时链接必须是https://github.com/rustfs/rustfs/compare/PREVIOUS_DELIVERABLE...target且基线必须与 preview Release 的基线一致示例1.0.0-beta.12-preview.1与1.0.0-beta.12都从1.0.0-beta.11对比。Preview 清理验证cleanup-preview-releases必须成功随后gh release view preview-tag对该目标的每个 preview 迭代都返回release not found而git rev-parse preview-tag^{commit}仍解析到PREVIEW_HASHTag 保留。若清理任务失败手工删除残留 Releasegh release delete preview-tag --yes并汇报。可选抽检从最终 Tag 产物运行./rustfs --version必须报告target。输出契约发布技能要求每次汇报固定包含五类信息Console 门禁结果之前的/最新的 Console Tag、合并变更是否需要发版、CONSOLE_HASH、发布时的 Console run/Release URL版本三元组目标版本、使用过的 preview Tag、PREVIEW_HASH两个 Tag 共同指向人工确认门禁状态WAITING_FOR_CONFIRMATION或CONFIRMED以及其绑定的精确 target、preview Tag、PREVIEW_HASH各阶段结果PASS/FAIL/BLOCKED及关键证据preview 与 final 的 Release URL、preview 的isPrerelease/isLatest状态、final 的 latest 通道状态、Console 检查结果、rc 命令矩阵、preview Release 清理结果已删除的 Releases 存活的 Tags任何对流水线的偏离及用户批准偏离的原因。十二、与仓库 CI 的对应关系从技能到源码发布技能描述的机制在仓库 CI 中均有落点可交叉印证Tag 触发构建与 Preview 分类.github/workflows/build.yml 中build-check对 tag push 依次判定preview-preview.digits、prerelease含 alpha/beta/rc、release其余非法-preview后缀 fail closed。构建矩阵、create-release/upload-release-assets/publish-release/update-latest-version、cleanup-preview-releases均定义于此文件。Docker 链式发布.github/workflows/docker.yml 在 job 级短路确保只有 tag push 且分支名不含-preview时才发布镜像——Preview 运行天然被跳过。Helm 发布.github/workflows/helm-package.yml 同样排除含-preview的触发。二进制版本自报rustfs/src/config/cli.rs 通过build::TAGshadow_rs 构建期注入与SHORT_VERSION实现「Tag 名 短 SHA」的版本输出是 Phase 4 校验./rustfs --version的源码基础。版本文件清单与映射规则.agents/skills/rustfs-release-version-bump/SKILL.md 规定了 7 个默认文件、beta.N - 0.N.0的 Chart 映射与rustfs.spec的Release后缀规则。读者可将本小节作为「技能文档 ↔ 仓库源码」的对照索引深入.github/workflows/与rustfs/src/config/继续研究。结语RustFS 的发布流水线把「版本号确认SemVer 门禁→ 代码验证Preview 预发布→ 人工确认Confirmation Gate→ 零差异发版同一 commit 打最终 Tag」串成一条可审计、可重试、可回滚的链路。其精髓在于三点版本号只写一次且不夹带-preview内部标识Preview 与 Final 共享同一PREVIEW_HASH杜绝「验证过 A、发布了 B」的偏差所有 latest 通道Docker、Helm、R2、latest.json只对最终 Tag 开放而 Preview 产物仅供人类与 rc 客户端验证。这套流程既是 RustFS 团队的内部工程规范也是一份可直接借鉴的开源项目发版实操模板。【免费下载链接】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），仅供参考