Prometheus 发布流程全解从版本排期、分支管理到打 Tag 发布的执行手册【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus本文基于 Prometheus 仓库中的 RELEASE.md 编写完整梳理官方发布流程的两大主题v3 系列的发布排期与发布牧人Release Shepherd制度以及单个版本从依赖更新、版本号提升、CHANGELOG 整理到打 Tag、发布库版本、跑基准测试的完整操作链路。读完后你将能够理解release-x.y分支的维护策略、VERSION文件与 UI 模块版本的联动关系并掌握scripts/generate_release_notes.sh、make ui-bump-version、scripts/get_module_version.sh等官方工具在发布中的具体用法。发布排期与 Release Shepherd 制度Prometheus 采用固定节奏 自愿认领的发布组织方式首个预发布pre-release的切出节奏为6 周一个 minor 版本每个 minor 版本由一位自愿认领的发布牧人release shepherd负责该 minor 的全部预发布与补丁版本。当前 RELEASE.md 中登记的排期表如下发布系列首个预发布日期年-月-日发布牧人v3.02024-11-14Jan Fajerskijan--fv3.12024-12-17Bryan Borehambborehamv3.22025-01-28Jan Fajerskijan--fv3.32025-03-11Ayoub Mrinimachine424v3.42025-04-29Jan-Otto Kröpkejkroepkev3.5 LTS2025-06-03Bryan Borehambborehamv3.62025-08-01Ayoub Mrinimachine424v3.72025-09-25Arthur Sens 与 György KrajcsovitsArthurSens、krajoramav3.82025-11-06Jan Fajerskijan--fv3.92025-12-18Bryan Borehambborehamv3.102026-02-05Ganesh Vernekarcodesomev3.112026-03-25Julien Pivottoroidelapluiev3.122026-05-06Bartek Plotkabwplotkav3.132026-06-17György Krajcsovitskrajoramav3.142026-07-29Ayoub Mrinimachine424v3.152026-09-09Jan Fajerskijan--fv3.162026-10-21虚位以待欢迎志愿者从排期表可以看出两个细节其一v3.5 被标记为LTS系列说明发布制度中预留了长期支持版本的定位其二当前仓库根目录的 VERSION 文件内容为3.14.0与排期表中 v3.14 的推进状态首个预发布定于 2026-07-29相吻合且 CHANGELOG.md 中最新的稳定版本条目为## 3.14.0 / 2026-08-17验证了排期表、版本号文件与变更日志三者在流程上是联动的。对排期表中volunteer welcome的空缺文档给出的参与方式是通过向 Prometheus 仓库提交 pull request在排期表中自荐成为所选 minor 系列的发布牧人。发布牧人的四项核心职责发布牧人负责一个 minor 版本从初始预发布到补丁版本的全部工作。流程正式始于首个预发布但准备工作需提前数天展开。文档明确了四项职责保持 main 分支随时可发布。目标是 main 分支在任何时刻都处于可用状态原则上任何时候都能从 main 切出发布。实际操作中牧人应在预发布日期前几天检查 main 的状态依其判断推动那些已在进行中、且理应赶上进本版本发布的 bug 修复尽快合入同时可以暂缓合并那些最后时刻的、侵入性强且风险高的变更把它们留给下一个 minor 版本。切出首个预发布后缀-rc.0。在排期表所列日期牧人切出第一个预发布并以该预发布所打的 tag 对应的 commit 为起点创建release-major.minor分支。预发布即release candidate候选发布因此原则上不应包含任何已知且计划在正式版本中修复的 bug。运行并监控 3 天基准测试。预发布切出后牧人需负责运行并监控该预发布为期 3 天的基准跑测benchmark若结果成功该预发布即可晋升promote为稳定版。处理回归与关键缺陷。一旦发现回归或严重 bug必须先修复再切出新的预发布命名依次为-rc.1、-rc.2等。分支管理与版本化策略官方发布流程声明采用语义化版本Semantic Versioning并且其分支策略是所有操作的结构性前提值得单独展开每个 minor 版本维护一个独立分支命名为release-major.minor例如release-2.1、release-3.0。分支保护规则任何以release-开头的分支名会自动触发仓库的分支保护机制。因此绝不要把非发布分支命名为release-开头否则该分支会意外进入受保护状态。常规合流路径新特性与一般变更合入mainbug 修复先合入最新的 release 分支再反向合回 mainmain 分支必须始终包含最新 release 分支的全部 commit只要 main 尚未与 release 分支产生分叉新 commit 也可以先提交到 main再把 main 合回 release 分支。cherry-pick 补救路径如果某次 bug 修复在 main 上已经混入了非 bug-fix 的变更之后才被合入 main则这些 bug-fix commit 必须被 cherry-pick 到 release 分支然后再合回 main。文档特别提示应尽量回避这种局面。旧版本分支的维护是 best effort尽力而为对较老 minor 版本的 release 分支维护采取尽力而为原则不做硬性承诺。此外文档还说明同一 major/minor 下的 release candidate 与补丁发布都发生在同一个release-major.minor分支内不要为补丁版本或 RC 另建release-version分支。发布前置依赖更新与实验特性晋级/降级在 major 或 minor 版本发布前的数天官方建议执行两类准备工作。依赖更新Prometheus 使用Dependabot持续自动更新大部分依赖其配置见 scripts/dependabot.yml因此多数依赖通常已是最新。牧人需要检查仓库中标记为 dependencies 的 PR 是否有未处理的更新。文档特别指出该机器人目前不管理Go 模块版本说明符中的incompatible与v0.0.0这两类非语义化版本这类情况需要手工处理make update-all-go-deps依赖更新后需要警惕各类怪异现象包括但不限于flaky 测试、资源占用变化、panic 等。若有疑虑或问题不能在合理时间内解决可以跳过依赖更新或仅更新部分依赖——但此时必须创建 issue 或 pull request 以便后续跟进。关于 UIReact 应用依赖文档说明 UI 已迁移到包含多个内部 npm 包的 monorepo 体系依赖升级目前相当敏感。查看仓库可印证这一结构web/ui/package.json 是名为prometheus-io的工作区根包其下还有prometheus-io/mantine-ui、prometheus-io/app位于 react-app 子目录、prometheus-io/codemirror-promql、prometheus-io/lezer-promql等多个内部包。升级 UI 依赖的命令为make update-npm-deps对应 Makefile 中的定义该目标实际调用 scripts/npm-deps.sh 脚本并传入minor参数即只做 minor 级别的依赖提升。此步骤完成后需要验证各模块子目录没有产生额外的node_modules目录那可能意味着跨模块的依赖版本冲突再运行make ui-build确认构建仍正常。文档还提到偶尔需要用make upgrade-npm-deps对应传入latest把 npm 依赖升级到最新 major/minor 版本但这可以在与发布节奏解耦的便利时机由 UI 维护者执行不必绑定每次发布。实验特性的晋级与移除依赖更新也是审视实验特性与 feature flag的好时机哪些应晋级为稳定stable、哪些应弃用deprecate或彻底移除。要求是每个特性一个独立的 pull request逐一处理。文档还给出一个校验步骤依赖更新后检查仓库的安全告警是否已全部关闭若告警不严重例如上游修复尚未发布、或与依赖升级无关、或确认不受影响则可以暂不处理。准备发布VERSION、CHANGELOG 与 UI 版本联动进入正式准备阶段以发布3.7.0为例上一稳定版为3.6.0基于 main 分支创建对应的release-3.7分支所有发布都在受保护的 release 分支上进行。RC 与补丁版本的变更一律通过 pull request 合入对应的 release 分支。提升 VERSION 文件中的版本号并更新 CHANGELOG.md。这一步必须走一个指向 release 分支的正式 PR——因为要让其他维护者有机会对发布内容本身、特别是对 CHANGELOG 条目发表意见。若为 release candidate版本号需追加类似-rc.0的后缀tag 名、release 名等相应同步修改。用脚本生成 CHANGELOG 草稿仓库提供 scripts/generate_release_notes.sh 来产出 CHANGELOG 条目的起点。它依赖release-notes工具与一个具备读权限的GITHUB_TOKEN运行方式为GITHUB_TOKENtoken scripts/generate_release_notes.sh 3.Y_SET_ME.Z_SET_ME版本参数可以是 RC、正式版或补丁号例如3.11.0-rc.0、3.11.0、3.11.1。从脚本源码可以看清它区分了两类生成逻辑minor 版本patch 为 0含其 RC 与正式版以vmajor.minor-1.0-rc.0tag 的父 commit 为起点、release-major.minor分支为终点覆盖上一个 minor 切分支以来的完整周期见 scripts/generate_release_notes.sh#L54-L67补丁版本以上一个补丁 tagvmajor.minor.patch-1为起点并加--skip-first-commit跳过起点 commit 本身见 scripts/generate_release_notes.sh#L68-L83。脚本内置的 Go 模板会按[SECURITY]、[CHANGE]、[FEATURE]、[ENHANCEMENT]、[PERF]、[BUGFIX]的优先级对 PR 标题前缀排序输出最终形态如 CHANGELOG.md 中的## 3.14.0 / 2026-08-17条目所示。文档要求仔细审阅输出后再写入 CHANGELOG.md重点是两条筛选原则删除已出现在上一版本 changelog 中的条目——由于修复可能先合入上一 release 分支重复条目很常见CHANGELOG.md 只记录对用户有相关性的变更外部 API 变化、性能改进、新特性。内部接口改动、代码重构与清理、构建流程变化等不应记录对这类变更感兴趣的人应参考 git 历史。提升 UI 模块版本完成上述工作后还需要提升 UI 模块的版本号make ui-bump-version查看 Makefile 中该目标的定义可以还原其完整动作先运行 scripts/get_module_version.sh 计算目标版本再调用 scripts/ui_release.sh 的--bump-version子命令随后在web/ui与web/ui/react-app两个工作区分别执行pnpm install并把pnpm-lock.yaml与所有package.json的变更一并git add。scripts/get_module_version.sh 的版本映射规则是理解 Prometheus 服务器版本 vs 库版本双轨制的钥匙对 major 为 2 的版本输出0.minor.patch如 v2.55.0 →0.55.0对 major 为 3 的版本输出0.3两位minor.patch如 v3.14.0 →0.314.0。当前仓库中 web/ui/package.json 的version字段恰为0.314.0与 VERSION 中的3.14.0完全对应——这正是该脚本在上一轮发布中被执行过的直接证据。以上所有变更VERSION 提升、CHANGELOG 更新、UI 版本提升与锁文件变更汇聚为一个指向release-x.y分支的 PR等待 CI 通过并获得批准。PR 合入 release 分支并同步到本地工作区后即可进入打 tag 环节。打 Tag 发布服务器版本服务器版本的发布通过以下命令完成tagv$( VERSION) git tag -s ${tag} -m ${tag} git push origin ${tag}也可以配置一个便捷的.gitconfigalias[alias] tag-release !f() { tagv${1:-$(cat VERSION)} ; git tag -s ${tag} -m ${tag} git push origin ${tag}; }; f然后执行git tag-release即可。用 GPG 密钥对 tag 签名是官方推荐做法若无法把 GPG key 添加到 GitHub 账号可将git tag的-s改为-a只做带注释的 tag 而不签名。tag 推送后GitHub Actions 会被该 tag 触发自动用prombot账号起草draftGitHub Release。此后的关键动作是等待该 tag 的构建步骤完成——标志是 tarball 已上传到 GitHub Release、容器镜像已推送到 Docker Hub 和 Quay.io——之后再点击Publish release使发布对外可见并产生 GitHub 通知。文档特别提醒对于 release candidate 版本务必确认草稿界面中勾选了This is a pre-release选项CI 应会处理这一点但点发布前人工复查一次更稳妥。仓库中的 .github/workflows/check_release_notes.yml 与 .github/workflows/prombench.yml 等 workflow 文件正是这套 tag 触发式自动化在仓库内的落点。打 Tag 发布库Go Module版本Go 模块的版本化要求严格使用语义化版本。由于 Prometheus不承诺服务器 minor 版本之间库代码不出现破坏性变更因此库采用**零主版本major version zero**策略服务器发 v3.x.y 时库对应发 v0.3xy.z。给库打 tag 的操作与常规发布类似但没有后续的构建与发布步骤tagv$(./scripts/get_module_version.sh) git tag -s ${tag} -m ${tag} git push origin ${tag}结合前文 scripts/get_module_version.sh 的解析逻辑这条命令会把VERSION中的3.14.0换算成库 tagv0.314.0。这个服务器 tag 与库 tag 分离打点的设计是 Prometheus 作为被大量第三方项目引用的 Go 库如配置、模型、抓取等包时保证依赖语义清晰的关键机制。收尾工作基准测试、合流与公告发布并非在点下Publish release后结束官方流程还有三个收尾动作对 RC 版本跑 3 天基准测试。对 release candidate如v3.6.0-rc.0使用/prombench vX.Y.Z命令触发基准跑测其中vX.Y.Z取上一个 minor 系列中最新稳定补丁版本的 tag例如上一系列为 3.5 时取v3.5.2。以稳定版为基线对比正是前文预发布需成功通过 3 天基准跑测后方可晋升为稳定版这一牧人职责的具体执行手段。把 release 分支的变更合回 main。若发布发生在最新的 release 分支上需将相关变更合并入 main维持main 始终包含最新 release 分支全部 commit的不变式。发布公告并寻找下一任牧人。二进制上传完成后在prometheus-announcegooglegroups.com邮件列表发布公告文档明确指出不要再使用prometheus-usersgooglegroups.com做发布通知可参考以往公告邮件的措辞。最后若排期表中下一版本还没有 release shepherd就要去找一位志愿者认领。小结Prometheus 的发布流程由制度与操作两层构成制度层是 6 周节奏的 minor 排期表与发布牧人负责制切 RC、盯 3 天基准、处理回归操作层则是从依赖更新Dependabot make update-all-go-deps/make update-npm-deps、实验特性晋级到 VERSION/CHANGELOG/UI 版本三处联动scripts/generate_release_notes.sh、make ui-bump-version、打服务器 tag 触发 GitHub Actions 自动起草发布、再打库 tagscripts/get_module_version.sh的版本映射的完整链路。分支模型main 与release-x.y的双向合流、cherry-pick 补救路径是贯穿其中的骨架。对于维护者而言RELEASE.md 与 Makefile、scripts 目录共同构成了一份可直接照做的发布操作手册对于使用者而言理解这套机制有助于解释版本号中-rc.x后缀的含义、UI npm 包0.3xy.z版本的由来以及为何某些修复会先出现在补丁版本中。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考