Apache APISIX 发布工程实践从 MAINTAIN.md 看补丁版与次版本发布的完整流程【免费下载链接】apisixThe Cloud-Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/ap/apisix本篇以仓库根目录的 MAINTAIN.md 为核心完整拆解 Apache APISIX 作为 Apache 顶级项目的版本发布流程补丁版patch14 步与次版本minor13 步的完整操作脉络并结合 Makefile、utils/gen-vote-contents.sh、utils/check-version.sh 等源码说明投票材料如何自动生成、版本号如何在源码各处保持一致。读完后你将掌握 APISIX 发布候选件RC的打包、签名、投票与登记全流程以及每个环节背后的工程实现。发布流程总览两条发布轨道MAINTAIN.md 将发布过程划分为两条独立轨道补丁版发布Release patch version针对已存在的release/x.yminor 分支回合并上次补丁发布以来标记了need backport的 PR再走投票、发布、登记流程共 14 步次版本发布Release minor version从主干拉出新的 minor 分支如release/3.9先向 master 发起 PR完成投票后再合并共 13 步。两条轨道共享同一套基础设施make release-src打包投票材料、Apache 邮件列表投票、reporter.apache.org发布登记、GitHub Release、RPM 包更新、Docker 镜像更新与 Helm chart 更新。差异主要在于补丁版需要先做回合并backport而次版本需要先建分支并在流程末尾才将分支合并回 master。补丁版发布14 步全流程以下 14 步完整继承自 MAINTAIN.md步骤中的外部操作邮件、投票链接等在文档中以真实历史示例给出此处按其语义说明。向 master 提交 changelog 与版本号变更 PR。changelog 只需提供指向对应 minor 分支的链接即指向该分支上的CHANGELOG.md对应锚点向 minor 分支提交回合并 PR。该 PR 需包含自上次补丁发布以来所有带need backport标签的 PR 的 backport 提交以及第 1 步的版本号变更。这些 PR 的标题需要同步追加到 minor 分支的 changelog 中将 PR 合并进 minor 分支**打包投票材料vote artifact**并上传到 Apache 的 dev-apisix 仓库命令为VERSIONx.y.z make release-src发送投票邮件到 devapisix.apache.org。执行VERSIONx.y.z make release-src后投票邮件内容会自动生成在./release目录下文件名为apache-apisix-${x.y.z}-vote-contents直接取用即可投票通过后发送投票结果邮件到 devapisix.apache.org将投票材料从 dev 仓库移入正式仓库Apache apisix 的 dist 目录在 reporter.apache.org 登记发布addrelease 页面从 minor 分支创建 GitHub Release文档中引用的示例 tag 为2.10.2若该版本号是全系列最大版本更新 APISIX 官网的版本展示更新 APISIX RPM 包到 apisix-build-tools 仓库创建名为apisix-${x.y.z}的新 tagCI 会自动将 RPM 包提交到 yum 仓库更新 APISIX Docker 镜像分两种情况版本号是最大版本更新 apisix-docker 仓库中的镜像配置PR 合并后从 master 拉出新分支release/apisix-${version}如release/apisix-2.10.2发布的是 LTS 版本且版本号小于当前最大版本如当前最大 2.14.1 而发布 LTS 2.13.2向 apisix-docker 仓库提交一个 PR以文档中的示例 PR 为模板分支命名release/apisix-${version}如release/apisix-2.13.2。PR 审阅通过后无需合并直接关闭 PR 并将该分支推送到 docker 仓库即可若版本号是最大版本更新 APISIX Helm chart发送 ANNOUNCE 邮件到 devapisix.apache.org 和 announceapache.org正式对外公告。次版本发布13 步全流程次版本发布的差异集中在先建分支、后合并主干完整步骤同样来自 MAINTAIN.md创建 minor 分支并从中向 master 发起 PR注意此时 PR 不合并打包投票材料VERSIONx.y.z make release-src发送投票邮件到 devapisix.apache.org材料同样自动生成于./release目录投票通过后发送投票结果邮件将投票材料移入正式仓库在 reporter.apache.org 登记发布从 minor 分支创建 GitHub Release文档示例 tag 为2.10.0将第 1 步的 PR 合并进 master 分支这是与补丁版流程的关键差异minor 分支内容最终并入主干更新 APISIX 官网更新 RPM 包在 apisix-build-tools 仓库打apisix-${x.y.z}tag 自动提交 yum 包更新 Docker 镜像两种分支/PR 情形与补丁版的第 12 步完全一致最大版本走新分支LTS 走审阅后关闭的 PR 并推送分支更新 Helm chart发送 ANNOUNCE 邮件到 devapisix.apache.org 和 announceapache.org。源码深潜make release-src做了什么MAINTAIN.md 中两条轨道共用的核心命令是VERSIONx.y.z make release-src。查看 Makefile 即可确认其完整行为链.PHONY: release-src release-src: compress-tar gpg --batch --yes --armor --detach-sig $(project_release_name).tgz shasum -a 512 $(project_release_name).tgz $(project_release_name).tgz.sha512 $(call func_check_folder,release) mv $(project_release_name).tgz release/$(project_release_name).tgz mv $(project_release_name).tgz.asc release/$(project_release_name).tgz.asc mv $(project_release_name).tgz.sha512 release/$(project_release_name).tgz.sha512 ./utils/gen-vote-contents.sh $(VERSION)它依赖compress-tar目标实际执行分为四段打源码包compress-tar用tar -zcvf将发布必需内容打包为apache-apisix-${VERSION}-src.tgz包含./apisix、./bin、./conf、apisix-$(VERSION)*.rockspec、apisix-master-0.rockspec、LICENSE、Makefile、NOTICE以及*.md文档。Makefile 中的注释特别说明$VERSION可以是major.minor.patch开发者本地执行时传入也可以是major.minorCI 中从分支名推导GPG 分离签名gpg --batch --yes --armor --detach-sig生成.asc签名文件对应投票材料中社区成员验证发布真伪的依据SHA-512 校验和shasum -a 512生成.sha512文件与 Apache dist 的 KEYS 密钥文件配合完成完整性校验归档并生成投票材料将.tgz、.asc、.sha512三个文件统一移入release/目录然后调用 utils/gen-vote-contents.sh 生成投票邮件文本。投票邮件是如何自动拼装的utils/gen-vote-contents.sh 的逻辑非常直接VERSION$1 SUBSTRING1$(echo $VERSION| cut -d. -f 1) SUBSTRING2$(echo $VERSION| cut -d. -f 2) BLOB_VERSION$SUBSTRING1.$SUBSTRING2 CHANGELOG_HASH$(printf $VERSION | sed s/\.//g) RELEASE_NOTE_PR.../release/$BLOB_VERSION/CHANGELOG.md#$CHANGELOG_HASH COMMIT_ID$(git rev-parse --short HEAD)脚本做三件关键事从x.y.z截取前两段拼出BLOB_VERSION如3.9构造出指向release/3.9分支上 CHANGELOG.md 的 changelog 锚点链接锚点即去掉点后的390例如#390这正对应 MAINTAIN.md 补丁版第 1 步changelog 只需提供指向 minor 分支的链接这一要求用git rev-parse --short HEAD取当前 HEAD 的短 commit id作为投票邮件中Release Commit ID的依据保证社区可以精确验证发布树对应哪个提交将上述信息连同候选件下载地址、KEYS 地址、以及完整的验证步骤wget下载、shasum -c校验、gpg --verify验签、tar zxvf解包、构建文档链接拼装为投票邮件正文最终写入./release/apache-apisix-$VERSION-vote-contents.txt。这意味着 MAINTAIN.md 中执行命令后投票邮件内容自动生成的描述并非口号而是release-src目标最后一条命令的确定性产物且邮件正文还内置了1 / 0 / -1的标准投票选项模板。版本号一致性从 version.lua 到 rockspec发布流程之所以要求第 1 步版本号变更必须随 PR 提交是因为 APISIX 的版本号散布在多处且需要保持一致。从仓库当前状态可以确认几个版本锚点运行时版本声明apisix/core/version.lua 以return { VERSION 3.9.0 }的形式声明当前版本这是网关运行时对自身版本的唯一来源变更日志CHANGELOG.md 以Table of Contents 版本锚点的方式组织当前最新条目为3.9.0锚点规则版本号去点后作为标题如#390正是 utils/gen-vote-contents.sh 中CHANGELOG_HASH变量的来源两处形成闭环LuaRocks 包描述apisix-master-0.rockspec 声明package apisixcompress-tar目标会将版本化命名的 rockspec 一并打入源码包保证从源码安装时元数据与版本匹配。此外仓库还保留了 utils/check-version.sh 脚本用于校验版本一致性它依次检查文档中所有apisix.x.y.z与version x.y.z字面量、源码中所有VERSION x.y.z声明以及根目录是否存在包含该版本号的 rockspec 文件任何一处不一致都会输出-----maybe wrong version-----并以非零码退出。从脚本结构看它面向的是版本变更 PR 的自查场景——这与 MAINTAIN.md 第 1 步要求版本号变更随 changelog PR 提交形成配合改版本号时须同步扫描上述各处锚点。外围发布产物RPM、Docker 与 Helm chart投票与 GitHub Release 完成之后MAINTAIN.md 还定义了三个对外分发通道的更新动作这也是 APISIX 区别于普通开源项目发布流程的部分产物更新方式触发条件RPM 包yum 仓库到 apisix-build-tools 仓库创建apisix-${x.y.z}tagCI 自动提交每次发布均执行Docker 镜像更新 apisix-docker 仓库并创建release/apisix-${version}分支LTS 场景走审阅后关闭的 PR 并直接推送分支每次发布均执行最大版本走标准分支流程低版本号 LTS 走特殊流程Helm chart更新 apisix-helm-chart 仓库仅当版本号为最大版本其中 Docker 的 LTS 特殊流程值得注意文档明确示例当前最大版本为 2.14.1而待发布的 LTS 为 2.13.2时不合并 PR只推送分支。从流程意图推断这是为了让 LTS 分支上的镜像构建与主干持续演进互不干扰避免低版本 tag 的镜像更新污染最高版本的构建链。小结MAINTAIN.md 定义的不是零散的发布清单而是一套完整的 Apache 发布工程链路版本与 changelog 先行版本号变更与 changelog 链接通过 PR 固化到 master 与 minor 分支打包自动化VERSIONx.y.z make release-src一条命令完成源码包、GPG 签名、SHA-512 校验和与投票邮件文本的生成其实现细节可见 Makefile 与 utils/gen-vote-contents.sh社区投票驱动发布投票邮件材料自动生成、投票期至少 72 小时、通过后移仓并登记 reporter多渠道分发收尾GitHub Release、RPMbuild-tools tag 触发、Dockerrelease 分支机制、Helm chart各自有明确的更新条件与例外路径。对于维护者或希望参与 APISIX 发布工作的开发者这份文档配合上述源码锚点足以在仓库内自行核对每一个环节的输入与输出。【免费下载链接】apisixThe Cloud-Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/ap/apisix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
