发布模型
发布模型¶
OpenStack 的开发围绕 6 个月的周期进行（例如“kilo”）。在每个 6 个月周期结束时，会发布所有 OpenStack 组件的同步版本，并提供一个通用的稳定分支，为下游团队（稳定分支维护、漏洞管理）和下游用户（特别是 OpenStack 发行版的打包者）提供一个方便的参考点。
大多数交付物遵循这个周期。如果它们的“最终”版本是开发周期中的唯一版本，它们可以在发布周期的最后阶段生成发布候选版本（cycle-with-rc 发布模型）。否则，它们可以选择在适当的时候直接发布（cycle-with-intermediary 发布模型）。
生成此“最终”版本的截止日期因交付物的类型而异。在一个开发周期中，非客户端库（“library”类型）最先，然后是客户端库（“client-library”类型），然后是服务和其他主要交付物（“service”和“other”类型），最后是发布跟踪交付物（“trailing”类型）。
最后，一些通常有用且不严格绑定到 OpenStack 开发周期的交付物可以使用 independent 发布模型独立于它发布。
根据交付物是什么以及它属于 OpenStack 地图中的哪个类别，适用许多规则
出现在 OpenStack 地图 中 *openstack* 类别中的组件构成了 OpenStack 云的主要组件，因此必须遵循发布周期。它们需要在 cycle-with-rc 或 cycle-with-intermediary 模型之间进行选择。
库不能使用 RC。它们需要在 cycle-with-intermediary 和 independent 发布模型之间进行选择。与 OpenStack 关系密切的库应优先选择 cycle-with-intermediary 模型，而通常有用的库应优先选择 independent 模型。
跟踪交付物落后于发布，因此从定义上讲，它们不能是独立的。它们需要在 cycle-with-rc 或 cycle-with-intermediary 模型之间进行选择。
cycle-with-rc¶
“cycle-with-rc”模型描述了在周期结束时生成单个版本，并在周期结束前发布一个或多个发布候选版本（RC）以及可选的开发里程碑 beta 版本的项目，具体发布时间取决于项目的需要。
“cycle-with-rc”项目承诺在周期开始前由发布管理团队发布的预定时间表后发布至少一个发布候选版本。
“cycle-with-rc”项目承诺生成一个版本以匹配开发周期的结束时间。
使用此标签的交付物的发布标签由发布管理团队审核和应用。
cycle-with-intermediary¶
“cycle-with-intermediary”模型描述了在开发周期内生成多个完整版本，并生成一个版本以匹配周期结束时间的那些项目。
“cycle-with-intermediary”项目承诺在 6 个月开发周期的结束时发布一个版本，该版本将与使用其他基于周期的发布模型且需要在此时间生成版本的项目一起使用。
使用此标签的交付物的发布标签由发布管理团队审核和应用。
independent¶
一些项目选择完全绕过 6 个月周期并独立发布。例如，这是支持开发基础设施的项目的情况。“independent”模型描述了这些项目。
“independent”项目会不时地发布版本。
使用此标签的交付物的发布标签的管理无需发布管理团队的监督。
abandoned¶
随着时间的推移，一些交付物会被放弃，因为它们不再有用，或者其功能被另一个交付物吸收。对于与周期绑定的发布模型，它们只是在下一个周期中消失。但是，具有周期独立模型的交付物只是保留在那里。
“abandoned”发布模型描述了一个正式独立的交付物，该交付物将不再发布，因为它更改了发布模型或因为已被放弃。
“abandoned”交付物绝不发布新版本。
untagged¶
一些 CI 工具仅从源代码使用，绝不标记发布版本，但需要创建稳定分支。
发布模型之间的转换¶
遗留发布模型¶
这些模型在以前的开发周期中可用，但已被替换或放弃。
cycle-trailing¶
注意
cycle-trailing 发布模型已被特定于“trailing”交付物类型所取代，该类型可应用于 cycle-with-rc 或 cycle-with-intermediary 发布模型。
“cycle-trailing”模型曾被生成 OpenStack 软件包、安装配方或生命周期管理工具的项目使用。这些项目仍然为每个开发周期生成一个版本，但它们在 OpenStack 本身发布之前无法发布。
“cycle-trailing”项目承诺在主版本发布后的 3 个月内或更晚发布一个版本。
使用此标签的交付物的发布标签由发布管理团队审核和应用。
cycle-automatic¶
注意
循环自动发布模型现在更好地由带有中间环节的循环模型结合稳定分支类型：无 来描述
“循环自动”模型被用于特定的技术交付物，这些交付物需要在一个周期结束时自动发布一次。 它们也可以选择在周期中间发布。 这些交付物不需要创建稳定分支。 这可能仅适用于 tempest-plugin 或 other 交付物。
“循环自动”交付物将由发布团队在每个周期结束时自动发布一次，使用仓库的当前 HEAD。 不会自动创建稳定分支。
使用此模型的交付物的发布标签由发布管理团队审查和应用。
带有里程碑的循环¶
注意
带有里程碑的循环发布模型已被带有 RC 的循环模型取代。
“带有里程碑的循环”模型描述了在周期结束时产生单个发布版本，并在周期计划中预定时间发布开发里程碑的项目。
“带有里程碑的循环”项目承诺在 6 个月周期的开始前，由发布管理团队发布的预定计划后发布开发里程碑。
“带有里程碑的循环”项目承诺生成与 6 个月开发周期结束相匹配的发布版本。
使用此标签的交付物的发布标签由发布管理团队审查和应用。
使用里程碑的项目预计每个周期至少标记 3 个中的 2 个，否则有被从官方项目中移除的风险。 发布团队会提醒错过第一个里程碑的项目，并在截止日期时通过标记 HEAD 为项目团队创建后续里程碑的标签。 如果发布团队在同一开发周期内为某个项目强制创建 2 个标签，则该项目将被视为非活动状态，并且发布团队将建议将其从官方项目列表中删除。
除非另有说明，本文档根据知识共享署名3.0许可协议授权。请参阅所有OpenStack法律文件。