Apache bRPC 发布全流程实战指南：从 Release Notes 到正式发布的分步操作手册-酒店常州论坛

Apache bRPC 发布全流程实战指南：从 Release Notes 到正式发布的分步操作手册

【免费下载链接】brpcbrpc is an Industrial-grade RPC framework using C++ Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. "brpc" means "better RPC".项目地址: https://gitcode.com/GitHub_Trending/brpc/brpc

Apache bRPC（即 brpc，一个工业级 C++ RPC 框架）作为 Apache 顶级项目，其每个版本的发布都必须遵循 Apache 基金会规定的"源码发布 + 签名校验 + 社区投票"完整流程。本文以仓库内 community/release_en.md 为骨架，结合仓库中的版本文件、构建配置与社区校验脚本，系统讲解从确认 Release Notes、配置 GPG 签名密钥，到制作源码包、发布至 Apache SVN、社区投票直至最终正式发布与公告的每一步操作，读完即可独立担任一次 Apache bRPC Release Manager，完成一个完整版本的发布。

一、发布准备（Preparation）

发布准备阶段通常耗时约1 周，核心目标是确认发布内容并备好签名工具链。

1.1 确认 Release Notes

在正式动工前，需要确认本次发布将要携带的Release Notes内容，要求：

本次发布计划包含的变更没有遗漏（对照 release 分支上已合并的 PR）；
每条变更的描述清晰明确，便于 PMC 与用户理解；
计划纳入本次版本的 PR 可以按时合并完成。

官方推荐的 Release Notes 模板如下：

[Release Notes] Feature: - ... Bugfix: - ... Enhancement: - ... Other: - ...

建议将 Feature / Bugfix / Enhancement / Other 分类填写，这份 Notes 会同时用于后续投票邮件与最终 ANNOUNCE 公告邮件，因此值得在此阶段仔细打磨。

1.2 配置 GPG 签名密钥（首次发布者必读）

Apache 要求所有发布制品必须有加密签名与校验和，因此 GPG（GnuPG）是发布流程的地基。如果你不是第一次发布，可以跳过本节。

1.2.1 安装 GPG

主流 Linux 发行版通常已预装 GnuPG。macOS 用户可用 Homebrew 安装：

brew install gnupg

也可以从 GnuPG 官网下载安装包。注意 GnuPG 1.x 与 2.x 的命令略有差异，本文示例基于GnuPG-2.3.1（macOS）。

安装完成后检查版本号：

gpg --version

1.2.2 创建密钥

执行以下命令创建密钥：

gpg --full-gen-key

按提示完成选择。邮箱必须使用 Apache 邮箱地址（如xxx@apache.org），Real Name可使用 Apache ID 或 GitHub ID。一次典型的交互过程如下：

Please select what kind of key you want: (1) RSA and RSA (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (9) ECC (sign and encrypt) *default* (10) ECC (sign only) (14) Existing key from card Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (3072) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: LorinLee Email address: lorinlee@apache.org Comment: lorinlee's key You selected this USER-ID: "LorinLee (lorinlee's key) <lorinlee@apache.org>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. # 输入密码

生成过程中系统会提示你敲击键盘、移动鼠标等以收集随机熵。完成后输出示例：

gpg: key 92E18A11B6585834 marked as ultimately trusted gpg: revocation certificate stored as '/Users/lilei/.gnupg/openpgp-revocs.d/C30F211F071894258497F46392E18A11B6585834.rev' public and secret key created and signed. pub rsa4096 2021-10-17 [SC] C30F211F071894258497F46392E18A11B6585834 uid LorinLee (lorinlee's key) <lorinlee@apache.org> sub rsa4096 2021-10-17 [E]

其中C30F211F071894258497F46392E18A11B6585834就是你的公钥 ID，92E18A11B6585834是短 ID。请务必妥善保管撤销证书（revocation certificate）与私钥口令。

1.2.3 检查生成的密钥

gpg --list-keys

输出示例：

gpg: checking the trustdb gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u /Users/lilei/.gnupg/pubring.kbx ---------------------------------- pub rsa4096 2021-10-17 [SC] C30F211F071894258497F46392E18A11B6585834 uid [ultimate] LorinLee (lorinlee's key) <lorinlee@apache.org> sub rsa4096 2021-10-17 [E]

注意：C30F211F071894258497F46392E18A11B6585834是完整的公钥 ID。

1.2.4 将公钥发布到密钥服务器

gpg --keyserver hkps://pgp.mit.edu --send-key C30F211F071894258497F46392E18A11B6585834

密钥服务器也可以选用hkps://keys.openpgp.org或hkps://keyserver.ubuntu.com（这两个提供网页查看密钥的功能）。

1.2.5 生成指纹并上传到 Apache 用户资料

由于公钥服务器没有验证机制，任何人都可以冒名上传公钥，因此通常还需要在自己的网站/资料页公布公钥指纹，供他人比对下载到的公钥是否可信。

查看指纹：

gpg --fingerprint lorinlee # user id

输出示例：

/Users/lilei/.gnupg/pubring.kbx ---------------------------------- pub rsa4096 2021-10-17 [SC] C30F 211F 0718 9425 8497 F463 92E1 8A11 B658 5834 uid [ultimate] LorinLee (lorinlee's key) <lorinlee@apache.org> sub rsa4096 2021-10-17 [E]

把指纹C30F 211F 0718 9425 8497 F463 92E1 8A11 B658 5834粘贴到 Apache 用户信息（id.apache.org）的OpenPGP Public Key Primary Fingerprint:字段中保存。此后任何人在校验发布签名时，都可以拿这个指纹与你公布的信息交叉核对。

二、制作发布（Make the release）

2.1 创建 release 分支

分支策略取决于版本类型：

发布新的 MAJOR/MINOR 版本（如1.0.0）：需要从 master 创建新分支release-1.0；
在既有 MINOR 版本上发布 PATCH 版本（如1.0.1）：只需在已有的release-1.0分支上修改并追加本次要发布的内容。

发布期间的所有代码修改都应在 release 分支（如release-1.0）上进行；发布完成后，需将 release 分支合并回 master。

2.2 更新 NOTICE 文件

检查并更新仓库根目录NOTICE文件中的YEAR（年份）字段。以当前仓库为例，NOTICE 文件内容为：

Apache bRPC Copyright 2018-2026 The Apache Software Foundation

年份应覆盖到发布当年；如发布跨年，需要把最新的年份补进区间。此外，若本次发布引入了携带 NOTICE 的第三方依赖，其 NOTICE 声明也需要按 Apache 规则并入发布版 NOTICE（见后文"检查发布内容"）。

2.3 更新源码中的版本号

Apache bRPC 的版本号分散在多个构建文件中，发布时必须逐一同步更新并提交。以1.0.0为例：

更新`RELEASE_VERSION`文件

编辑仓库根目录的 RELEASE_VERSION 文件，更新版本号并提交。当前仓库该文件内容为：

1.17.0

更新`CMakeLists.txt`

编辑仓库根目录的 CMakeLists.txt，更新BRPC_VERSION变量并提交。当前仓库第 45 行为：

set(BRPC_VERSION 1.17.0)

该变量会被 CMake 构建系统用于生成BRPC_VERSION宏及安装包元信息，是 C++ 源码层版本号的唯一来源。

更新`package/rpm/brpc.spec`

编辑 package/rpm/brpc.spec，更新Version字段并提交。当前仓库该文件第 20-21 行为：

Name: brpc Version: 1.17.0

同时该文件中的Source0也指向https://downloads.apache.org/brpc/%{version}/apache-brpc-%{version}-src.tar.gz，说明 RPM 打包直接依赖正式发布目录中的源码包，因此版本号必须与最终发布的制品严格一致。

更新`MODULE.bazel`

编辑仓库根目录的 MODULE.bazel，更新module(...)中的version字段并提交。当前仓库第 18-22 行为：

module( name = 'brpc', version = '1.17.0', compatibility_level = 1, )

Bazel BCR（Bazel Central Registry）依赖解析会以此版本号区分不同模块版本，同样不能遗漏。

小结：一个版本号需要同步维护在RELEASE_VERSION、CMakeLists.txt、package/rpm/brpc.spec、MODULE.bazel四处（当前仓库均为1.17.0），发布时请逐一核对，避免 CMake/Bazel/RPM 三套构建体系版本不一致。

2.4 创建发布 tag

将 release 分支拉到本地并打 annotated tag（附注标签，包含标签作者与信息）：

git clone -b release-1.0 git@github.com:apache/brpc.git ~/brpc cd ~/brpc git tag -a 1.0.0 -m "release 1.0.0" git push origin --tags

使用-a创建附注标签而非轻量标签，是 Apache 发布审计的常见要求，便于追溯发布点。

2.5 生成发布源码包

使用git archive从 tag 生成带统一前缀的源码包，两种写法等价：

git archive --format=tar 1.0.0 --prefix=apache-brpc-1.0.0-src/ | gzip > apache-brpc-1.0.0-src.tar.gz

或

git archive --format=tar.gz 1.0.0 --prefix=apache-brpc-1.0.0-src/ --output=apache-brpc-1.0.0-src.tar.gz

--prefix参数保证解包后所有文件位于apache-brpc-1.0.0-src/目录下，这是 Apache 发布包的标准目录命名（apache-<项目>-<版本>-src）。

2.6 生成 GPG 签名

对源码包做分离式 ASCII 签名（detached ASCII-armored signature）：

gpg -u lorinlee@apache.org --armor --output apache-brpc-1.0.0-src.tar.gz.asc --detach-sign apache-brpc-1.0.0-src.tar.gz

然后立即自验一次：

gpg --verify apache-brpc-1.0.0-src.tar.gz.asc apache-brpc-1.0.0-src.tar.gz

-u指定签名使用的 key（当本地存在多个 key 时尤其重要），--armor输出文本格式便于在网页/邮件中展示。

2.7 生成 SHA512 校验和

sha512sum apache-brpc-1.0.0-src.tar.gz > apache-brpc-1.0.0-src.tar.gz.sha512 sha512sum --check apache-brpc-1.0.0-src.tar.gz.sha512

此时发布目录应包含三件套：源码包apache-brpc-1.0.0-src.tar.gz、GPG 签名.asc、SHA512 校验和.sha512。

三、发布到 Apache SVN 仓库（Publish to Apache SVN repository）

3.1 Checkout dist/dev/brpc 目录

Apache 的候选发布（Release Candidate）统一放在dist/dev目录。先创建本地工作目录并 checkout，--username使用你自己的 Apache LDAP 用户名：

mkdir -p ~/brpc_svn/dev/ cd ~/brpc_svn/dev/ svn --username=lorinlee co https://dist.apache.org/repos/dist/dev/brpc/ cd ~/brpc_svn/dev/brpc

3.2 添加 GPG 公钥到 KEYS 文件

新任 Release Manager 首次发布时必须把自己的公钥追加进KEYS文件（该文件位于 SVN 仓库根目录，供验证者下载导入）：

(gpg --list-sigs lorinlee && gpg -a --export lorinlee) >> KEYS

如果本地有多个使用同一名字的 key，应显式指定 key。按邮箱指定：

(gpg --list-sigs lorinlee@apache.org && gpg -a --export lorinlee@apache.org) >> KEYS

按指纹指定：

(gpg --list-sigs C30F211F071894258497F46392E18A11B6585834 && gpg -a --export C30F211F071894258497F46392E18A11B6585834) >> KEYS

3.3 将发布包放入 SVN 目录

mkdir -p ~/brpc_svn/dev/brpc/1.0.0 cd ~/brpc_svn/dev/brpc/1.0.0 cp ~/brpc/apache-brpc-1.0.0-src.tar.gz ~/brpc_svn/dev/brpc/1.0.0 cp ~/brpc/apache-brpc-1.0.0-src.tar.gz.asc ~/brpc_svn/dev/brpc/1.0.0 cp ~/brpc/apache-brpc-1.0.0-src.tar.gz.sha512 ~/brpc_svn/dev/brpc/1.0.0

3.4 提交 SVN

回到父目录，用 Apache LDAP 账号提交：

cd ~/brpc_svn/dev/brpc svn add * svn --username=lorinlee commit -m "release 1.0.0"

提交后，候选版本即可通过https://dist.apache.org/repos/dist/dev/brpc/1.0.0/被所有验证者访问。

四、验证发布（Verify release）

此环节是 Apache 发布流程中**验证者（而非发布者）**最常执行的步骤。仓库社区目录中还提供了配套的自动化校验脚本 community/apache-package-validator.sh 与检查清单 community/releasecheck.md，可与下面的手工步骤互补。

验证前进入候选版本目录：

cd ~/brpc_svn/dev/brpc/1.0.0

4.1 验证 SHA512 校验和

sha512sum --check apache-brpc-1.0.0-src.tar.gz.sha512

4.2 验证 GPG 签名

首先导入发布者的公钥（发布者本人可跳过，验证者必须导入）。从 SVN 仓库拉取KEYS并导入：

curl https://dist.apache.org/repos/dist/dev/brpc/KEYS >> KEYS gpg --import KEYS

然后信任发布者的签名。用发布者的用户名进入编辑界面：

gpg --edit-key lorinlee

交互过程：

gpg> trust Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y gpg> save

最后验证签名：

gpg --verify apache-brpc-1.0.0-src.tar.gz.asc apache-brpc-1.0.0-src.tar.gz

4.3 检查发布内容

4.3.1 与 GitHub tag 源码包做差异对比

应使用tar.gz格式的 tag 包进行对比：

curl -Lo tag-1.0.0.tar.gz https://github.com/apache/brpc/archive/refs/tags/1.0.0.tar.gz tar xvzf tag-1.0.0.tar.gz tar xvzf apache-brpc-1.0.0-src.tar.gz diff -r brpc-1.0.0 apache-brpc-1.0.0-src

diff -r无输出即说明候选源码包与 tag 完全一致。

4.3.2 文件内容合规检查

对照 Apache 的 Source Release 验证要求与常见否决原因（见下图），逐项检查：

源码包中是否包含多余文件导致 tarball 过大；
LICENSE与NOTICE文件是否存在（对应仓库根目录 LICENSE 与 NOTICE）；
NOTICE文件中的年份是否正确；
只应包含文本文件，不应包含二进制文件（如.jar、.o、编译产物等）；
所有文件开头是否有 ASF 许可头（Apache License header）；
源码能否正确编译、单元测试能否通过；
是否存在冗余文件/文件夹（如空目录）；
第三方依赖许可证检查：
- 第三方依赖许可证与 Apache License 是否兼容；
- 所有第三方依赖的许可证是否已在LICENSE文件中声明；
- 依赖许可证的完整版本是否位于 license 目录；
- 若第三方依赖为 Apache License 且带有 NOTICE 文件，其 NOTICE 内容也需并入发布版 NOTICE。

社区维护的 community/releasecheck.md 与 community/apache-package-validator.sh 正是围绕上两图所列检查项实现的自动化工具，发布者与验证者都可以直接复用。

五、在 Apache bRPC 社区发起投票（Vote in the Apache bRPC community）

投票阶段预计耗时3 天以上。

5.1 投票流程

向dev@brpc.apache.org发送投票邮件。PMC 成员需根据本文档核对版本正确性后投票。至少经过 72 小时且获得 3 个 PMC 成员的 +1 票，方可进入下一阶段；
公布投票结果，并将投票结果邮件发送至dev@brpc.apache.org。

5.2 投票邮件模板

（1）Apache bRPC 社区投票邮件模板

标题：

[VOTE] Release Apache bRPC 1.0.0

内容（注意：Release Commit ID填写当前 release 分支最后一个提交的 commit ID）：

Hi Apache bRPC Community, This is a call for vote to release Apache bRPC version 1.0.0 [Release Note] - xxx The release candidates: https://dist.apache.org/repos/dist/dev/brpc/1.0.0/ Git tag for the release: https://github.com/apache/brpc/releases/tag/1.0.0 Release Commit ID: https://github.com/apache/brpc/commit/xxx Keys to verify the Release Candidate: https://dist.apache.org/repos/dist/dev/brpc/KEYS The vote will be open for at least 72 hours or until the necessary number of votes are reached. Please vote accordingly: [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove with the reason PMC vote is +1 binding, all others are +1 non-binding. Checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] Source code distributions have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each brpc repo. [ ] All files have license headers if necessary. [ ] No compiled archives bundled in source archive. Regards, LorinLee

其中投票选项的含义为：+1赞同、+0无意见、-1反对并需附理由；PMC 的 +1 为 binding（有约束力）票，其他人为 non-binding（无约束力）票。

（2）投票结果公布邮件模板

标题：

[Result] [VOTE] Release Apache bRPC 1.0.0

内容：

Hi all, The vote to release Apache bRPC 1.0.0 has passed. The vote PASSED with 3 binding +1, 3 non binding +1 and no -1 votes: Binding votes: - xxx - yyy - zzz Non-binding votes: - aaa - bbb - ccc Vote thread: xxx (vote email link in https://lists.apache.org/) Thank you to all the above members to help us to verify and vote for the 1.0.0 release. I will process to publish the release and send ANNOUNCE. Regards, LorinLee

5.3 投票未通过

如果社区投票未通过，需要修改 release 分支代码，重新打包、重新发起投票。此时应仔细阅读 -1 票附带的理由（常见原因见 community/releasefail.png 所列项），修正后走完新一轮验证与投票流程。

六、完成发布（Finish the release）

6.1 将发布包从 dist/dev 移动到 dist/release

仅限 PMC 成员操作，若KEYS有变动也会一并同步：

svn mv https://dist.apache.org/repos/dist/dev/brpc/1.0.0 https://dist.apache.org/repos/dist/release/brpc/1.0.0 -m "release brpc 1.0.0"

6.2 创建 GitHub Release

在 GitHub Releases 页面找到对应版本 tag，点击创建新 Release；
编辑版本号与版本描述，点击Publish release。

6.3 更新下载页面

等待并确认新版本同步到 Apache 镜像之后，更新 brpc 官网下载页面（通过修改 brpc-website 仓库的代码实现），中英文页面都需要更新。下载链接前缀规则：

GPG 签名文件与哈希校验文件使用前缀：https://downloads.apache.org/brpc/；
源码包下载链接使用前缀：https://dlcdn.apache.org/brpc/。

6.4 发送发布完成公告邮件

向dev@brpc.apache.org和announce@apache.org发送公告邮件。注意事项：

邮箱账号必须使用个人 Apache 邮箱；
邮件内容必须是纯文本格式（plain text mode）；
发送到announce@apache.org的邮件会经过人工审核，发送后请耐心等待，通常一天内通过。

公告邮件模板：

标题：

[ANNOUNCE] Apache bRPC 1.0.0 released

内容（Brief notes of this release只需列出本次发布的主要变更，不必列出贡献者与 PR 编号，建议参考上一次公告邮件）：

Hi all, The Apache bRPC community is glad to announce the new release of Apache bRPC 1.0.0. Apache bRPC is an Industrial-grade RPC framework using C++ Language, which is often used in high performance systems such as Search, Storage, Machine learning, Advertisement, Recommendation etc. Brief notes of this release: - xxx - yyy - zzz More details regarding Apache brpc can be found at: https://brpc.apache.org/ The release is available for download at: https://brpc.apache.org/download/ The release notes can be found here: https://github.com/apache/brpc/releases/tag/1.0.0 Website: https://brpc.apache.org/ Apache bRPC Resources: - Issue: https://github.com/apache/brpc/issues/ - Mailing list: dev@brpc.apache.org - Documents: https://brpc.apache.org/docs/ We would like to thank all contributors of the Apache bRPC community who made this release possible! Best Regards, Apache bRPC Community

6.5 发布微信公众号公告

参考历史公告样式，在 bRPC 官方微信公众号同步发布本次版本发布消息。

6.6 更新 master 分支

发布完成后，将 release 分支合并回master分支，确保主干代码与发布版本保持一致，并保留版本号更新记录。

七、发布全流程速查

阶段	关键动作	产物/出口
准备	确认 Release Notes；配置 GPG 密钥并上传指纹	签名密钥、Notes 草稿
制作	建 release 分支；更新 NOTICE、RELEASE_VERSION、CMakeLists.txt、package/rpm/brpc.spec、MODULE.bazel；打 tag	tag、`apache-brpc-<ver>-src.tar.gz`+`.asc`+`.sha512`
发布到 SVN	上传至 dist/dev 并提交，追加 KEYS	dist/dev 候选目录
验证	SHA512 校验、GPG 签名验证、与 tag 对比、合规检查	验证通过结论
投票	dev@ 邮件投票，≥72h 且 ≥3 个 binding +1	投票结果邮件
完成	svn mv 至 dist/release；GitHub Release；更新下载页；ANNOUNCE 邮件；合并 master	正式版本

整个流程中最容易被忽略的两个细节是：版本号在四份构建文件中必须同步更新（当前仓库版本为1.17.0，分别见 RELEASE_VERSION、CMakeLists.txt、package/rpm/brpc.spec、MODULE.bazel），以及验证阶段对第三方许可证的逐项核对——这两处一旦出错，轻则导致构建产物版本不一致，重则直接收获 -1 否决票。按照本文步骤逐项执行，即可顺利完成一次合规的 Apache bRPC 版本发布。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析