Release Management¶

OpenStack 项目团队会产生大量代码仓库。有些是提供基础设施 API 的服务，有些是这些服务使用的库，还有一些是支持组件和工具。其中大部分会在特定时间点正式发布。我们称这些为交付物，并使用 git 标签来定义发布点。每个交付物可能包含一个或多个 git 仓库，所有仓库会在同一时刻被标记为相同的版本。

Release management 团队处理的交付物¶

Release Management 项目团队通常负责处理所有官方 OpenStack 交付物的发布管理，具体由技术委员会确定。这保证了所有“OpenStack”软件的统一性和基本的发布管理标准。

每个项目团队生成的官方 OpenStack 交付物在 reference/projects.yaml 文件中描述，该文件位于 openstack/governance 仓库中。默认情况下，release management 团队通过从 openstack/releases git 仓库的更改建议驱动的自动化流程来处理所有这些交付物的发布管理。

此一般规则的例外情况在交付物定义（在 reference/projects.yaml 文件中）中使用 release-management 键记录。

release-management: none 表示该交付物未发布，不需要任何发布管理。例如，specs 仓库、cookiecutter 仓库等。
release-management: external 表示该交付物在单独的发布平台上发布，其发布由其项目团队直接管理。这应保持例外情况，通常仅限于部署工具等边缘情况。例如，Chef 菜谱发布在 Chef 超市，OpenStack Charms 发布在 Charm 商店。
release-management: deprecated 表示虽然它目前存在于 reference/projects.yaml 中，但该交付物很快将被移除，不应再发布。

Release management 团队会定期检查 governance 中定义的交付物与 openstack/releases git 仓库中的交付物文件是否一致。

Release cycle¶

OpenStack 开发遵循共同的时间周期发布流程。这导致在开发周期结束时，构成“OpenStack”发布的所有组件的协调发布。

您可以通过关注 releases 网站上最新系列的“schedule”链接来查找当前开发周期的计划。

这些组件在周期内发布的时间和频率取决于交付物类型（服务、库等）和所选的发布模型。交付物类型在 release management 团队文档的 deliverable types section 中描述。发布模型在 release management 团队文档的 release models section 中描述。

一些交付物，例如不特定于 OpenStack 的通用库，可以在发布周期之外完全独立地发布，采用 independent 发布模型。

Choosing a release model¶

对于每个 OpenStack 交付物，您应该选择可用的发布模型之一。以下是一些关于如何根据所考虑的交付物类型进行选择的指导。

库¶

库有三种不同的风格：OpenStack 客户端库、其他 OpenStack 特定库和通用库。

OpenStack 客户端库必须选择 cycle-with-intermediary 模型。在这种模型中，它们会尽早且频繁地发布，以便快速向使用服务的服务提供新功能。为此，release management 团队将为在每个开发周期里程碑至少发布一次的库提出发布，假设存在重大更改。

其他 OpenStack 特定库和通用库可以选择 cycle-with-intermediary 模型，也可以选择 independent 发布模型。后一种选择可能是有意义的，如果该库与 OpenStack 没有任何实际联系，或者它主要是稳定且功能完整的。

Services, Horizon plugins and other deliverables¶

其他 OpenStack 组件（包括服务、Horizon 插件和其他交付物）必须遵守发布周期。它们可以在 cycle-with-rc 模型和 cycle-with-intermediary 模型之间进行选择。

cycle-with-rc 模型是历史上的 OpenStack 发布模型。在这种模型中，在开发周期的末尾为包含在协调的 OpenStack 发布中生成单个发布。主要发布号（X.Y.Z 数字中的 X）会为每个发布系列递增。

在周期接近结束时，这些交付物会进入 Feature Freeze 阶段。要求他们停止合并添加新功能、新依赖项、新的配置选项、数据库模式更改、字符串更改等使打包者、翻译者、文档编写者或测试人员工作更困难的代码。Feature Freeze Exceptions（“FFE”）可能会由项目 PTL（或发布联络人）例外授予，但每个接受的 FFE 都会导致更多的工作，减少在发布候选版本中测试和修复问题的花费时间，从而降低最终发布的质量。

一旦交付物被认为准备好了，就会创建一个第一个发布候选版本（“RC1”），以及一个稳定的分支，可以在该分支上修复发布关键问题并创建进一步的发布候选版本。主分支开始进入新的开发周期，不再进行功能冻结。

在最终发布日，Release Team 将获取每个项目的最后一个发布候选版本，并将其重新标记为最终发布版本。除了版本号之外，最后一个发布候选版本和最终版本之间没有区别。稳定分支随后进入稳定维护团队的管理，并根据稳定分支规则进行回溯。

另一种模型是 cycle-with-intermediary 模型。它允许您在想要的时间、尽可能频繁地发布。唯一的期望是到 RC1 目标周，应该从最新的可用版本创建稳定分支。可以从该稳定分支创建点发布，以修复发现的发布关键问题。在协调的发布日期，稳定分支上可用的最新版本将包含在 OpenStack 发布中。

在这个模型中，为了为稳定的点发布腾出空间并避免版本冲突，我们至少在下一个开发周期的第一个发布中增加次要号（X.Y.Z 中的 Y）。编号否则遵循语义版本控制规则。

cycle-with-intermediary 模型适用于您希望尽早且频繁地发布、不需要过多地完善最终发布或不希望有太多指导和流程来生成发布的情况。仍然建议在接近开发周期结束时专注于错误修复并搁置重大破坏性功能，以确保给定开发周期的最终发布尽可能可用且无错误。

Trailing the common cycle¶

部署和生命周期管理工具通常希望遵循发布周期，但由于它们依赖于其他项目的完成，因此它们有更多的时间来发布最终版本。

如果他们计划进行一次发布并希望使用 RC，他们应该选择 cycle-with-rc 模型。如果他们想要更多灵活性并且不使用 RC，他们应该选择 cycle-with-intermediary 模型。

How to release ?¶

发布通常每周发生（或更频繁），通常安排在一天中的早期和一周的早期，基于库维护者的时区。这种安排为维护者提供了充足的时间来处理新发布后出现的问题，以最大程度地减少任何停机时间，而无需在正常工作时间之外进行额外工作，例如与周末重叠。

从技术上讲，发布是通过将签名标签推送到与该交付物关联的 git 仓库来创建的。CI 系统识别新的签名标签，并触发构建包、将其上传到分发服务器（我们的 tarball 站点和 Python Package Index）以及发送电子邮件公告的作业。

有关设置支持自动发布的仓库的更多详细信息，请参阅《Infrastructure User Manual》中的 Project Creator’s Guide。

标记和发布过程容易出错。为了正确审查提议的标签并在将标签实际推送到之前运行测试，我们使用特定的仓库 openstack/releases 来提交发布请求。发布请求由项目的 PTL 或发布联络人以对该仓库的相应“deliverables”文件的补丁形式提出。有关更多详细信息，请参阅该仓库中的 README 文件。

这些请求然后由 Release Team 自动测试、审查和处理，通常避免周末，因为那时没有人可以帮助处理潜在的发布自动化问题。

Release Liaisons¶

与其他的跨项目团队一样，release management 团队依赖于每个参与项目的联络人来帮助协调和发布相关的任务。联络人通常是 PTL，但 PTL 也可以通过更新 openstack/releases 仓库中的 data/release_liaisons.txt 文件中的联络人列表，将责任委派给团队中的其他人。

Liaison Responsibilities¶

联络人不必亲自完成所有这些事情，但必须确保项目团队中的某人完成它们。

监控发布计划并提醒团队成员截止日期。
确保项目中的发布相关补丁得到及时审查。

有时，团队需要合并更改到他们的项目中，以保持与 release team 实践的同步。release team 依赖于联络人来帮助进行并审查这些更改，以避免阻止未来的发布。例如，保持需求列表的最新状态、添加工具和更新打包文件。
提交或验证发布请求。如果请求不是由联络人或 PTL 提交的，其中一方必须表示他们的批准。
协调开发周期结束时的功能冻结例外情况（FFE），并跟踪需要完成才能发布的阻塞错误修复和功能工作。

功能冻结和发布之间的时期应该用于稳定新功能和修复错误。但是，对于每个发布，总有一些“必须具备”的功能，由于各种原因，未能及时完成。由项目团队决定允许哪些功能在截止日期之后，哪些功能将被推迟到下一个发布。联络人负责跟踪任何开放的功能冻结例外情况，并帮助项目团队专注于及时完成工作。
在 OFTC 的 #openstack-release IRC 频道中随时待命，以回答问题和解决问题。

对于 release team 来说，有太多的项目可以加入所有项目的频道。请在您使用 IRC 时加入中央发布频道。
监控和参与有关发布主题的邮件列表讨论。

release management 团队与其他项目团队之间的主要沟通方式是 openstack-discuss 邮件列表。联络人必须订阅并确保他们关注带有主题“[release]”的线程。注意与截止日期、需要进行的发布更改等相关的说明。
在 openstack/governance 仓库（reference/projects.yaml）中保持项目交付物列表（以及相关的 git 仓库）的最新状态。

Typical Development Cycle Schedule¶

OpenStack 开发周期遵循重复的模式，这里从一般意义上描述该模式。由于假期、活动安排和其他因素，里程碑之间的时间长度可能会从周期到周期发生变化，因此请咨询 releases 网站上的实际“Under development”计划以获取实际计划。

Weeks Leading to Milestone 1¶

通常 4-6 周

讨论周期目标
完成蓝图和规范讨论
周期其余部分的奠基工作

里程碑 2 前几周¶

通常 5-6 周

正常的开发工作

里程碑 3 前几周¶

通常 4-6 周

推迟一些目标，重新关注关键优先级
功能开发完成
错误修复
稳定化工作

功能冻结 -1¶

在完全功能冻结前一周，我们准备 Oslo 和其他非客户端库的最终发布版本，以便消耗项目的项目有时间稳定，并且所有者可以准备错误修复（如果需要）。

最终 Oslo 和非客户端库发布

注意

如果认为对发布至关重要且更新导致回归的风险较低，可以请求针对影响项目发布的库的例外情况。

要请求在冻结后发布库的例外情况，请将带有以下标签的主题行发送到 openstack-discuss 邮件列表

[release][requirements][other-impacted-projects]

发布和需求团队将评估风险并提供反馈。

如果可能，最好等到冻结结束后再发布库的稳定版本。

里程碑 3 / 功能冻结¶

针对带有 RC 交付项的周期，功能开发停止（“功能冻结”）
消息字符串停止更改（“字符串冻结”），以便翻译团队有时间完成他们的工作
依赖项规范停止更改（“需求冻结”），以便打包人员有时间准备软件包
所有项目的客户端库的最终发布版本。请注意，阻塞其他项目的特性需要比这更早地发布，因为项目在功能冻结和需求冻结期间将无法采用它们。

功能冻结 +1¶

最终功能冻结例外情况合并
为所有库创建稳定分支

发布候选期，发布 -3¶

发布候选期持续数周，通常在功能冻结后的一周开始。

带有 RC 的项目发布他们的第一个发布候选版本
为交付项创建发布分支
在项目交付项 yaml 文件中提交周期亮点。有关周期亮点的信息，请参阅下文。

在此期间，提交到新分支并合并的补丁应仔细管理。
1. 在此期间避免激进的回溯，因为大量的待处理评审会消耗评审资源，并使理解哪些补丁是发布阻塞变得更加困难。
2. 所有代码补丁应先合并到主分支，然后才能批准合并到新的发布分支。
3. 应快速合并翻译更新，以确保它们包含在最终发布版本中。
4. 应快速合并需求同步补丁，以确保它们包含在最终发布版本中。

发布 -2¶

为全局需求列表和测试工具（如 devstack 和 grenade）创建稳定分支
在主分支上解除全局需求列表的冻结
冻结所有库发布，除了独立发布的库（这些库仍然可以发布，尽管约束和需求更改将保留到冻结期结束时）

发布 -1¶

最终发布候选版本和组件的发布，用于包含在最终发布版本中。

发布 0¶

紧急最后一分钟的发布候选版本（不太可能）
在本周星期四早上将最终发布候选版本标记为官方发布版本
所有库发布在主分支上冻结

管理发布说明¶

OpenStack 交付项的发布说明是在项目的源存储库中使用 reno 进行管理的。 reno 文档解释了该工具的一般工作方式，以下说明解释了如何在您的项目中设置它。

目录结构¶

大多数项目都有一个 doc/source 目录，其中配置了 Sphinx 以构建面向开发者的文档，最终在 https://docs.openstack.org/developer/$PROJECT 下发布。发布说明不是面向开发者的，因此需要单独发布，这意味着源树中需要一个单独的 Sphinx 项目。运行发布说明构建的作业期望在 releasenotes/source 中找到该项目。

reno 读取的发布说明文件应保存在 releasenotes/notes 中。仅将发布说明 YAML 文件放在此目录中。

在您的项目中设置发布说明工具¶

发布说明是从主分支的配置构建的，并从所有应发布说明的稳定分支中提取说明。首先按照以下步骤配置主分支构建，然后将必要的更改回溯到您希望使用 reno 的稳定分支。

使用 sphinx-quickstart 设置一个新的 Sphinx 项目。交互式提示将询问将新文件放在哪里。如果您从 git 存储库的根目录运行该工具，则回答 releasenotes/source 将产生正确的结果。
编辑 releasenotes/source/conf.py 以更改 extensions 列表，以包含 'reno.sphinxext'。

编辑 releasenotes/source/conf.py 并添加

# -- Options for Internationalization output ------------------------------
locale_dirs = ['locale/']

编辑 test-requirements.txt 以添加 reno。确保使用全局需求列表中的当前条目以避免版本冲突。
创建一个目录 releasenotes/notes 并添加一个空 .placeholder 文件以确保 git 跟踪该目录。
创建一个文件来保存“当前”分支的发布说明，使用不指定显式分支的 release-notes 指令。该文件由测试作业使用，以确保稳定分支上的补丁不会引入破坏主分支上实际发布说明构建作业的发布说明。例如，Glance 使用 releasenotes/source/unreleased.rst 包含
```
==============================
 Current Series Release Notes
==============================

.. release-notes::
```
为计划使用 reno 管理发布说明的每个稳定分支创建一个单独的文件。使用 release-notes 指令为每个系列生成正确的发布说明。例如，liberty 版本表示在名为 releasenotes/source/liberty.rst 的文件中包含
```
==============================
 Liberty Series Release Notes
==============================

.. release-notes::
   :branch: stable/liberty
```
编辑 releasenotes/source/index.rst 以删除大部分自动生成的內容，并将其替换为标题和引用您在上一步中创建的分支文件的 toctree。

更新 tox.ini 以添加一个 releasenotes 测试环境，方法是添加

[testenv:releasenotes]
commands = sphinx-build -a -W -E -d releasenotes/build/doctrees -b html releasenotes/source releasenotes/build/html

编辑 Zuul 配置（通常是一个 .zuul.yaml 文件或位于仓库顶部的 .zuul.d 子目录中的一组文件）。找到 project: 部分，并在其 templates: 列表中添加一个 release-notes-jobs-python3 条目，如下所示

- project:
  templates:
    - check-requirements
    - integrated-gate-compute
    ...
    - publish-openstack-docs-pti
    - release-notes-jobs-python3
  check:
    jobs:
      ...

将以上所有更改作为一个补丁一起提交。例如，请参阅 https://review.openstack.org/241323 和 https://review.openstack.org/243302（Glance 使用 2 个单独的补丁设置）。

注意

对任何正在使用 reno 进行发布说明的现有稳定分支重复此过程，一直回溯到 stable/liberty。虽然我们不在分支中运行 reno 来发布说明，但我们在测试作业中运行它，以确保稳定分支中的发布说明更改不会破坏主分支上的发布说明构建。

如何添加新的发布说明¶

reno 扫描 git 历史记录以查找发布说明文件和标签，以确定哪些说明属于每个发布版本。这意味着您需要在发布版本标记之前将发布说明放入将在其中生成发布版本的分支中。可以稍后编辑说明文件，但它们始终会出现在系列中的第一个版本中。

通常，应随同合并到主分支的修复程序一起添加发布说明，然后在修复程序回溯到较旧的稳定分支时将其包含在内。由于每个系列的发布说明是单独生成的，因此相同的说明可能会出现在多个版本的输出中。

如果由于某种原因，说明不适用于主分支，则可以直接将其添加到稳定分支。

使用 reno new 生成一个带有唯一后缀值的新发布说明文件。 reno 创建的唯一文件名可确保在修复程序回溯时不会发生合并冲突。例如

$ tox -e venv -- reno new bug-XXX

创建新文件后，编辑它以删除任何不相关的部分，并在适当的部分中添加说明。请参阅 reno 文档的 Editing a Release Note 部分，了解有关 YAML 文件每个部分的内容以及有关格式化说明的提示。

要查看渲染后的新发布说明版本，需要提交更改，以便 reno 可以在 git 日志中找到说明文件，然后构建发布说明文档。

$ git commit  # Commit the change because reno scans git log.

$ tox -e releasenotes

然后在 Web 浏览器中查看 releasenotes/build/html 中的生成的发布说明文件。

何时添加发布说明¶

补丁的发布说明应包含在补丁中。如果不是，则应在后续评审中包含发布说明。

如果补丁满足以下任何条件，建议添加发布说明。

升级
- 部署者在升级时需要采取操作
- 添加了一个新的配置选项，部署者应考虑更改默认值
- 弃用了配置选项
- 删除了配置选项
特性
- 实现了一个新功能
- 标记了一个功能以供弃用
- 删除了一个功能
- 默认行为已更改
错误
- 修复了一个安全漏洞
- 修复了一个长期存在的或重要的错误
API
- 驱动程序接口或其他插件 API 已更改
- REST API 已更改

并非每个补丁都值得发布说明。用户可能会在发布后浏览十几个或更多项目的发布说明，应仔细考虑有用的内容和噪音。

如何编写好的发布说明¶

发布说明应从用户的角度和他们应该知道的内容来编写。以下是一些在编写它们时要记住的示例问题

从最终用户/部署者的角度来看，什么特别相关？
对他们有什么变化？
他们需要特别做什么吗？
这种变化会影响他们的日常使用吗？

发布说明不应替代 git 提交消息。它们应侧重于对用户的影响，并使其易于理解，即使对于不了解补丁或项目的完整技术背景的人也是如此。

更新稳定分支发布说明¶

偶尔需要更新过去版本的发布说明。发布说明需要与普通代码回溯不同地处理。

注意

由于 reno 解析发布说明的方式，如果在主分支上更新说明而不是其原始稳定分支，则它将出现在后续版本的发布说明中。

请参阅 reno 用户文档，了解有关正确 Update stable branch release notes 的详细信息。

如何在 RC 时间预览发布说明¶

OpenStack 项目在通用周期中，具有开发里程碑的项目通常会在每个里程碑和发布候选版本被标记之前添加一个发布说明。这些说明将出现在同一个生成的页面上，但按标签分隔。然而，当稳定分支被标记为最终发布版本后，当生成发布说明时，它们将全部合并到一个说明中。如果您遵循上述关于发布说明中包含内容（并在适当的补丁中包含发布说明）的建议，那么您可能会有一些带有序言的部分，一些没有序言的部分，以及所有部分的情况。在发布之前，您可能想查看生成的单个说明的确切样子，以便您可以按照用户将要阅读的顺序阅读整个说明。以下是一种方法可以做到这一点

从 git 克隆一个新的仓库，或者确保您的副本已完全更新。
假设您正在准备 Pike 发布版，它将被标记为 ‘15.0.0’ 并在 ‘stable/pike’ 分支中准备。签出 stable/pike 分支并在您的本地仓库中为发布创建标签：git tag 15.0.0
签出 master 分支，并以通常的方式生成发布说明：tox -e releasenotes
浏览到 releasenotes/build/html 目录中的生成的说明
完成校对后，删除标签：git tag -d 15.0.0

SLURP 发布版的发布说明¶

从 2023.1 OpenStack 发布版开始，每个“点版本”发布版将被指定为 SLURP（跳级升级发布流程）发布版。这样的发布版将支持从直接之前的发布版（即，遵循传统的 OpenStack 升级流程）或从之前的 SLURP 发布版进行升级。（有关详细信息，请参阅发布节奏调整决议。）

支持 SLURP 和传统发布流程的一个含义是，从一个 SLURP 升级到下一个 SLURP 的操作员可能看不到 SLURP 之间的发布说明。同时，遵循传统发布升级流程的操作员不应该阅读非 SLURP 发布说明两次。（这是因为如果人们被迫重读一堆东西，他们的眼睛更有可能变得茫然，并且他们会错过一些新的重要内容。）

因此，我们需要使非 SLURP 发布说明易于从 SLURP 发布说明中发现，既要避免它们使 SLURP 说明混乱，又要方便尚未阅读过它们的操作员使用。如果所有项目都遵循相同的基本结构来执行此操作，那么发现将会得到增强，其结构如下所述。

第一个 SLURP 发布版是 2023.1，紧随其后的发布版（非 SLURP）是 2023.2，紧随其后的发布版是 2024.1（SLURP 发布版）。遵循 SLURP 策略的部署者将直接从 2023.1 升级到 2024.1，跳过 2023.2。假设 2024.1 尚未发布，并且您现在正在完成 2024.1（第二个 SLURP）发布说明。

生成 2023.2（SLURP 减 1）发布说明的静态页面。
- 何时：在 2023.2 发布后不久（“不久”意味着在任何发布说明更正合并到 stable/2023.2 后，但在任何包含新发布说明的反向移植合并到 stable/2023.2 之前）
  - 由于 reno 的工作方式，稳定分支中的发布说明更正必须直接在稳定分支中进行。因此，如果静态文件生成得太早，您将错过任何更正，并且需要手动将其应用于静态文件（实际上这并不是什么大问题）。
- 如何：从项目仓库的根目录
```
$ tox -e releasenotes --notest

$ .tox/releasenotes/bin/reno report \
     --title "2023.2 Release Notes" \
     --branch "stable/2023.2" | \
    sed 's/^ *$//g' > "releasenotes/source/2023.2-static.rst"
```
- 需要注意的几点
  - “常规”发布说明中的标题始终是“X 系列发布说明”。请注意，我们使用的是不同的标题，即“X 发布说明”。这是因为 reno 在生成 .rst 文件中的锚点时使用标题，我们需要静态文档中的锚点是唯一的。
  - 确保在写入的文件名中包含“-static”。目录中已经存在一个 xena.rst 文件，我们不想覆盖它。（该文件用于该系列的“常规”发布说明，将继续以正常方式生成补丁反向移植后。）
  - 为什么要使用额外的静态 .rst 文件？有三个原因
    - 与自非 SLURP 2023.2 协调发布以来的更改相关的任何发布说明将自动包含在后续 SLURP 发布版的说明中，因为 OpenStack 反向移植流程规定必须先将更改合并到发布 n+1，然后才能将其合并到发布 n。我们不想重复这些内容。
    - 提供一个静态 .rst 文件将允许您在静态文件中包含锚点，以便您的 SLURP 发布说明可以链接到静态页面中的特定项目。
    - 如果需要，还可以手动编辑静态文件，以强调与 SLURP 相关的内容（或删除如果说明非常长，则不相关的内容）。
编辑（并提交）静态发布说明页面。
- 何时：在生成它后立即
- 静态 .rst 文件的顶部应该如下所示
```
====================
2023.2 Release Notes
====================

.. _2023.2 Release Notes_23.0.0_stable_2023.2:

23.0.0
======

.. _2023.2 Release Notes_23.0.0_stable_2023.2_Prelude:

Prelude
-------

.. releasenotes/notes/2023.2-prelude-25dc371d85fb6610.yaml @ b'7ee5824c64b1c3c85d1ce1636bdecd86acb64970'

Welcome to the 2023.2 (Bobcat) release of the OpenStack Block Storage
service (cinder). With this release, we added several drivers ...
```
- 您必须对静态 .rst 文件进行以下更改。我们不希望它包含在发布说明的 toctree 中；它的唯一目的是从 SLURP 发布说明中链接到它。因此，我们需要在页面顶部添加一个 :orphan: 指令，以便 sphinx 不生成警告（openstack 发布说明作业将警告视为错误，从而导致您的发布说明构建失败）。它应该是文件中的第一个非注释非空白字符
```
:orphan:

====================
2023.2 Release Notes
====================

etc.
```
- 不要忘记对静态文件执行“git add”，因为您需要将其提交到仓库。

从 SLURP 发布说明中添加指向静态页面的链接。

何时：在准备 SLURP 发布版（在本例中为 2024.1）的最终说明时

内容：在 SLURP 发布版的“序言”部分添加一个包含指向静态页面的链接的项目。您可以在常规 reno .yaml 文件中执行此操作。例如，

---
prelude: |
    Welcome to the 2024.1 release of the OpenStack Block Storage
    service (cinder) ...

    * Something important about this release.

    * Another important thing to mention.

    * **This is a SLURP release.**  If you are upgrading directly
      from the previous SLURP release (2023.1), we recommend that
      you read through the :doc:`release notes from the
      intermediate release <2023.2-static>` (2023.2).

可能有一些来自中间非 SLURP 发布版的重要项目，项目团队可能希望在 SLURP 发布说明中重新强调它们。完全可以。我们只是要求您谨慎地执行此操作，以便部署者不会认为他们可以完全忽略中间发布版的其他说明（必须很重要，否则您为什么一开始要写它们？）。由于中间非 SLURP 发布说明保存在静态 .rst 文档中，因此您不必重复整个说明。相反，您可以添加一个指向您想要强调的特定项目的锚点，然后从 SLURP 发布说明中链接到它。

最后，截至撰写本文时，我们正处于第一个 SLURP 时代非 SLURP 发布版（即 2023.2）的开发周期中，并且尚未真正拥有可以从之前的 SLURP 发布版升级的 SLURP 发布版。因此，我们完全预计发布说明流程会随着项目团队和部署者适应它而演变。但希望这种简单的方法是一个好的开始。

周期亮点¶

周期亮点提供了一个高级、以用户为中心的最新发布版中发生变化的摘要。这不一定是您在发布版中完成的最复杂的技术工作，但这是对用户影响最大的工作。周期亮点会自动填充 releases.openstack.org/$RELEASE/highlights.html 处的发布亮点页面。

添加周期亮点¶

周期亮点应与 RC1 一起提交。这通过在 openstack/releases 仓库中的 deliverables/$RELEASE/$PROJECT.yaml 中添加信息来完成。您应该包括 3-5 个周期亮点项目符号。

cycle-highlights:
  - Introduced new service to use unused host to mine bitcoin
  - Merged code from shade, os-client-config and openstacksdk into
    a single library to create a unified and simpler our client-side library
  - Added Rescue Mode to let users recover from lost SSH keys and
    misconfigurations

您可以通过在本地运行来检查输出的格式

tox -e docs

并检查 doc/build/html/$RELEASE/highlights.html 下的生成文件，或者您可以查看 build-openstack-sphinx-docs 作业在 html/$RELEASE/highlights.html 下的输出。

编写好的周期亮点¶

与开发人员的提交消息或操作员的 reno 发布说明不同，周期亮点旨在让产品经理、新闻工作者、营销人员、不负责操作的用户等了解本发布版对他们的变化。您提交 3-5 个周期亮点项目符号，格式如下：

发生了什么变化/引入了什么，它对用户有什么作用/好处

亮点应保持相当简短——目标长度小于两行。

通过在 RC1 或尽可能接近 RC1 时提交您的亮点，发布管理团队将能够提供编辑并帮助您编写展示您工作的周期亮点。

发布管理

Release Management¶