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

版本发布

OpenStack每6个月发布一个版本，有不同的发布模式，项目可以选择遵循其中一种。

本部分允许您：

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

• 了解不同发布模式的结构以及如何有效地工作以影响OpenStack的未来

发布模式

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

当前有如下几种可用模式：

• cycle-with-rc

• cycle-with-intermediary

• cycle-trailing

• cycle-automatic

• independent

• untagged

发布排期和计划

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

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

发布周期的第一个阶段主要关注计划，这就是为什么PTG会被安排在紧跟每个版本发布之后的原因。在这个阶段，你应该上传你的specs以供审查，并且通过邮件列表、IRC项目频道和IRC会议等途径来讨论你的设计中任何可能存在问题的部分。

在第一个里程碑之后，一些项目更多地关注开发和错误修复活动，而其他项目可能仍然会接受在该周期中实施的新想法。

The third period of a release is focusing on finishing the implementation and testing of new functionality added during the release. You need to ensure to add new tests in Tempest and have documentation covered as well before the third milestone. During this phase the core review team can choose to focus on higher priority features only. They make their decision about priorities either at the PTG or soon after, some time before the first milestone of a release.

Some projects also have different dates through a release cycles as internal, project-specific deadlines, like spec-freeze or code-freeze. You need to make sure you are aware of the freeze dates which you can find on the release schedule page.

After the third milestone the community is focusing on stabilizing the release by putting more emphasis on testing and fixing bugs. The projects following the release cycle have their release candidates tagged after the third milestone. There are no limits to release candidates, but the goal is to keep the number low and fix all the critical issues that got identified by milestone-3.

Having the main projects following the release cycle ensures that all these projects release at the same time so these can be picked up by downstream teams to package and further distribute.

稳定分支

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

自发布后，stable分支被维持为对影响较大的bug和安全问题进行的修复的稳妥来源，这些问题已在master分支上得到修复。 鉴于这些分支的稳定性，当试图对稳定分支进行向后移植(backport)时会受到额外的盘查(scrutiny)。 拟议的变更应：

• 引入回归(introducing a regression)的风险很低

• 有用户可见的好处

• 自成一体

• 包含在master中并向后移植到master和存在问题的stable分支之间的所有版本中

Project teams do point releases off stable branches when enough changes accumulate in the stable branch to justify creating another release for their project.

Stable branches proceed through different levels of maintenance as they age.

状态	大体时间	摘要
Maintained	Approximately 18 months	All appropriate bug fixes accepted and releases are produced.
Extended Maintenance	While there are community members maintaining it.	All appropriate bug fixes accepted. No releases are produced and there is reduced CI commitment.
Unmaintained	6 months from the time the branch is made unmaintained.	The branch is under Extended Maintenance rules, but there are no maintainers.
End of Life (EOL)	N/A	Branch is no longer accepting Changes.

Before the Ocata release the Maintained and Extended Maintenance phases were only 6 months long. This meant that each release went End of Life after 18 months. It was determined that this practice was not beneficial for distributors or users of OpenStack. As a result the Maintained state was updated to last 18 months and the Extended Maitenance time frame was made flexible increasing the number of stable branches still accepting fixes.

The state of all OpenStack releases may be seen on the OpenStack Releases web page.

For more detailed information on Stable Branches and their maintenance phases see the Stable Branches page.