本篇翻译自doc/developer/frr-release-procedure.rst
``<version>`` - 即将发布的版本，例如 7.3
``origin`` - FRR 上游存储库
一、第 1 阶段 - 准备
- 为新版本准备更新日志
注意：使用 ``tools/release_notes.py``来帮助起草发行说明更新日志
2.检测现有的 ``dev/<version>`` 分支。
git checkout dev/<version>
3.根据 ``dev/<version>`` 分支创建并推送一个名为 ``stable/<version>`` 的新分支。
git checkout -b stable/<version>
4.删除名为``dev/<version>``的开发分支
git push origin --delete dev/<version>
5.更新 Red Hat 软件包的更新日志:
编辑 ：file：`redhat/frr.spec.in` 并查找 ``%changelog`` 部分：
5.1 将最后一个（列表顶部）条目从``%{version}``更改为上次发布的版本号。例如，如果 ``<version>`` 是 ``7.3``，而最后一个公开版本是 ``7.2``，则可以使用 ``7.2``，更改文件，如下所示：
* Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - %{version}
改为
* Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - 7.2
5.2. 在列表顶部添加带有“%{version}”标记的新条目。请务必注意格式，即日期始终为 2 个字符，如果日期为 1 位数字，则第 1 个字符为空格。
5.3. 在此条目下方添加更改日志文本。
6. 更新 Debian 软件包的更新日志：
更新 :file:`debian/changelog`:
- 使用最后的发行版号和debian修订版（通常为-1）作为``dch --newversion VERSION``的参数运行以下命令。例如，如果 ``<version>`` 为 ``7.3``，则将运行 ``dch --newversion 7.3-1``。
- ``dch`` 将运行一个编辑器，您应该在此条目下方添加更改日志文本，通常为：**New upstream version**。
- 使用 ``dpkg-parsechangelog`` 验证变更日志格式。在存储库根目录中：
dpkg-parsechangelog
您应该看到如下输出：
7.提交更改，将更改日志添加到提交消息中。遵循所有现有的提交准则。提交消息应类似于：
debian, redhat: updating changelog for new release
8. 更改主版本号:
8.1 编辑 ：file：'configure.ac' 并将 ``AC_INIT`` 命令中的版本更改为 ``<version>``
添加并提交此更改。此提交应与包含更改日志的提交分开。提交消息应为：
FRR Release <version>
版本字段应完整;即对于``8.0.0``，版本应为``8.0.0``，而不是``8.0``或``8``。
二、第 2 阶段 - 暂存
- 将稳定分支推送到以``rc``： 为前缀的新远程分支：
git push origin stable/<version>:rc/version
这将触发 NetDEF CI，该 CI 用作发布分支上的健全性检查。验证所有测试是否通过，以及所有包生成是否成功。为此，请转到位于此处的 NetDEF CI：
https://ci1.netdef.org/browse/FRR-FRR
在左上角的``Plan branch``下拉列表中查找``rc-<version>``。选择此版本。请注意，CI 可能需要几分钟时间才能启动此新分支并显示在列表中。
2.推送稳定分支：
git push origin stable/<version>:refs/heads/stable/<version>
3. 为版本创建并推送 git 标签：
git tag -a frr-<version> -m "FRRouting Release <version>"
4. 基于 ``master`` 创建一个新分支，挑选之前添加更改日志的提交，并使用它来创建针对 ``master`` 的 PR。这样，``master``就有了下一个周期的最新更新日志。
5. 在 CI 系统上启动"Release"构建计划，以获得正确的发布。有关此步骤，请联系 Martin Winter。确保所有发布包都成功生成。
6. 启动该版本的 Snapcraft 构建计划。
三、第 3 阶段 - 发布
- 将 Debian 和 RPM 软件包上传到各自的存储库。
- 与 FRR 的 RPM 存储库的维护者协调，以在该存储库上发布 RPM 包。更新存储库网页。验证网页上的说明是否有效，以及 FRR 是否可以从 Red Hat 系统的存储库安装。
当前维护者: *Martin Winter*
3.与 FRR Debian 软件包的维护者协调，在该存储库上发布 Debian 软件包。更新存储库网页。验证网页上的说明是否有效，以及 FRR 是否可以从 Debian 系统的存储库安装。
当前维护者: *Jafar Al-Gharaibeh*
4.登录到 Read The Docs 实例。 在“FRRouting”项目中，导航到“概述”选项卡。 确保列出了“stable-<version>”版本并已启用该版本。转到“管理员”，然后转到“高级设置”。将“默认版本”更改为新版本。这样可以确保默认情况下向访问者显示的文档是最新版本的文档。
此步骤必须由对“读取文档”实例具有管理访问权限的人员执行。
5.在 GitHub 上，转到 <https://github.com/FRRouting/frr/releases>_ 并单击“起草新版本”。编写发布公告。发布公告应遵循本文档旁边的“release-announcement-template.md”中的模板。检查拼写错误，并可选择（但最好）让其他维护人员校对公告文本。
不要将任何包或源码压缩包附加到 GitHub 版本。 审核后发布版本。
6. 部署 Snapcraft 版本。请记住，这将自动升级 Snap 用户。
当前维护者： *Martin Winter*
7.生成并发布 Docker 容器。
当前维护者： *Quentin Young*
8.克隆 ``frr-www`` 存储库：
git clone https://github.com/FRRouting/frr-www.git
9. 使用以前的公告作为模板添加新的发布公告：
cp content/release/<old-version>.md content/release/<new-version>.md
将 GitHub 发布公告文本粘贴到此文档中，并删除换行符。换句话说，这是：
This is one continous
sentence that should be
rendered on one line
需要改成这样：
This is one continous sentence that should be rendered on one line
这非常重要，否则公告将无法在网站上阅读。
要获取提交者和提交的数量，这里有几个方便的命令：
# The number of commits
%git log --oneline --no-merges base_8.2...base_8.1 | wc -l
# The number of commiters
%git shortlog --summary --no-merges base_8.2...base_8.1 | wc -l
请确保在顶部添加指向 GitHub 版本页面的链接。
10.在 frrouting.org Web 服务器上部署更新的“frr-www”，并验证公告文本是否可见。
11. https://docs.frrouting.org 的更新 readthedocs.org（默认版本）是此最新版本的版本。
12. 发送电子邮件至 “announce@lists.frrouting.org”。这封电子邮件的文本应包括 GitHub 版本中的适当文本，以及指向 GitHub 版本、Debian 存储库和 RPM 存储库的链接。
936
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
