FRRouting项目发布流程详解

FRRouting项目发布流程详解

frr The FRRouting Protocol Suite 项目地址: https://gitcode.com/gh_mirrors/fr/frr

前言

FRRouting(简称FRR)作为一款开源路由协议栈，其发布流程遵循严格的标准化操作。本文将详细介绍FRR项目的完整发布流程，帮助开发者理解如何从开发分支准备到最终发布的全过程。

发布前准备

数据平面API版本检查

在正式发布前，首先需要检查zebra/zebra_dplane.h文件中的数据平面API变更情况：

1. 对比上一个发布版本以来的API变更
2. 根据变更性质决定版本号更新：
   • 重大API变更：更新主版本号
   • 次要API变更：更新次版本号
3. 版本号定义在zebra/zebra_dplane.c文件中

第一阶段：发布准备

变更日志生成

使用项目提供的tools/release_notes.py工具生成变更日志：

./tools/release_notes.py -b dev/9.1 -t frr-9.0.1

参数说明：

• -b：指定将被重命名为stable分支的开发分支
• -t：指定作为变更基准的上一个发布标签

分支管理操作

1. 检出开发分支：

   git checkout dev/<version>
   

2. 创建稳定分支：

   git checkout -b stable/<version>
   

3. 删除开发分支：

   git push origin --delete dev/<version>
   

包管理文件更新

Red Hat RPM包更新

编辑redhat/frr.spec.in文件：

1. 更新%changelog部分
2. 将顶部条目版本号改为上一个发布版本
3. 添加新条目并使用%{version}标签
4. 添加变更日志内容

Debian包更新

更新debian/changelog文件：

1. 使用dch工具更新版本：

   dch --newversion 7.3-1
   

2. 添加变更内容（通常为"New upstream version"）

3. 验证变更日志格式：

   dpkg-parsechangelog
   

版本号更新

编辑configure.ac文件，更新AC_INIT命令中的版本号，并提交变更：

git commit -m "FRR Release <version>"

第二阶段：发布候选

CI验证

1. 推送RC分支：

   git push origin stable/<version>:rc/version
   

2. 在CI系统中验证rc-<version>分支的测试结果

正式分支推送

git push origin stable/<version>:refs/heads/stable/<version>

标签创建

git tag -a frr-<version> -m "FRRouting Release <version>"
git push origin frr-<version>

主分支更新

1. 基于master创建新分支
2. 挑选变更日志提交
3. 创建PR合并到master分支

构建验证

1. 触发CI系统的"Release"构建计划
2. 触发Snapcraft构建计划
3. 构建Docker多架构镜像

第三阶段：正式发布

包发布

1. 上传Debian和RPM包到各自仓库
2. 协调维护者更新仓库网页和安装指南

文档更新

1. 在Read The Docs中启用stable-<version>版本
2. 设置新版本为默认文档版本

GitHub发布

1. 创建新发布
2. 使用release-announcement-template.md模板编写发布公告
3. 不附加任何包或源码压缩包

网站更新

1. 克隆网站仓库
2. 创建新版本发布公告
3. 移除文本中的换行符
4. 部署更新后的网站

公告发送

1. 发送邮件至公告列表
2. 包含GitHub发布链接和包仓库信息

结语

FRRouting项目的发布流程体现了开源项目的严谨性，从API版本检查到最终的公告发布，每个环节都经过精心设计。理解这一流程不仅有助于项目维护者进行版本发布，也能让贡献者更好地参与项目开发。

frr The FRRouting Protocol Suite 项目地址: https://gitcode.com/gh_mirrors/fr/frr