[ English | 한국어 (대한민국) | Indonesia | 中文 (简体, 中国) | español (México) | English (United Kingdom) | Deutsch ]

发布

OpenStack 具有 6 个月的发布周期，项目可以选择遵循不同的发布模式。

本节允许您

• 了解 OpenStack 组件遵循的不同发布模式

• 了解不同发布模式的结构，以及如何有效地参与其中，以影响 OpenStack 的未来

发布模式

OpenStack 由大量项目组成，这些项目构成了 OpenStack 云的主要组件，从客户端库到生命周期管理服务。不同的项目性质不同，这意味着它们需要遵循不同的 发布模式。

当前可用的选项如下：

• cycle-with-rc

• cycle-with-intermediary

• cycle-trailing

• cycle-automatic

• independent

• untagged

发布计划和规划

大多数官方 OpenStack 项目遵循发布管理团队设定的发布计划。

6 个月的周期分为三个里程碑和一个通常为期一个月的稳定期，期间会发布候选版本。

周期的第一阶段更侧重于规划，这就是为什么 PTG 会在发布后立即安排。这是您应该上传您的规范以供审查，并使用邮件列表、项目频道和 IRC 上的会议来讨论您的设计中可能存在疑问的任何部分的时候。

在第一个里程碑之后，一些项目更侧重于开发和错误修复活动，而其他项目可能仍然接受新的想法以在该周期内实现。

发布的第三阶段侧重于完成新功能的实现和测试。您需要在第三个里程碑之前确保添加新的 Tempest 测试并覆盖文档。在此阶段，核心评审团队可以选择仅关注优先级更高的功能。他们会在 PTG 或紧随其后的一段时间内（在发布的第一里程碑之前）做出关于优先级的决定。

一些项目在发布周期内也有不同的日期作为内部、项目特定的截止日期，例如规范冻结或代码冻结。您需要确保您了解冻结日期，可以在 发布计划页面 上找到这些日期。

在第三个里程碑之后，社区专注于通过更加重视测试和修复错误来稳定发布。遵循发布周期的项目会在第三个里程碑之后标记其候选版本。候选版本没有限制，但目标是保持数量较少并修复里程碑 3 中发现的所有关键问题。

主要项目遵循发布周期，确保所有这些项目同时发布，以便下游团队可以打包和进一步分发。

稳定分支

一旦完成 6 个月的开发周期，该版本的代码就会在 git 中分支到稳定分支。例如，当 Stein 发布完成时，会在 git 中创建一个新的分支，stable/stein。

稳定分支被视为对自发布以来在主分支上修复的高影响错误和安全问题的安全来源。鉴于这些分支的稳定性质，对稳定分支的移植会经过额外的审查。建议的更改应

• 具有很低的引入回归的风险

• 具有用户可见的好处

• 是自包含的

• 包含在主分支中，并移植到主分支和所讨论的稳定分支之间的所有发布版本中（请参阅 移植）

项目团队会在稳定分支上积累足够的更改时，发布稳定分支的点版本，以证明为他们的项目创建另一个版本是合理的。

随着稳定分支的成熟，它们会经历不同的维护级别。

状态	时间范围	摘要
维护中	大约 18 个月	接受所有适当的错误修复并生成发布版本。
未维护	虽然有社区成员在维护它。	接受所有适当的错误修复。不生成发布版本，并且减少了 CI 承诺。
生命周期结束 (EOL)	不适用	分支不再接受更改。

未维护状态只是为了让感兴趣的各方在给定稳定版本维护阶段结束后进行进一步维护的共同场所，但正如其名称所示，它不被官方认为是维护状态。

所有 OpenStack 版本的状态可以在 OpenStack Releases 网页上查看。

有关稳定分支及其维护阶段的更详细信息，请参阅 稳定分支 页面。