将 Ironic 迁移到基于功能的发布模型¶
https://blueprints.launchpad.net/ironic/+spec/feature-based-releases
在温哥华的 Liberty 设计峰会上，Ironic 团队普遍同意将 Ironic 项目迁移到基于功能的发布模型。[0] 本规范旨在说明我们这样做以及如何操作的原因。
问题描述¶
Ironic 当前使用传统的 OpenStack 发布模型。[1] 这包括
每六个月发布一个版本。
在发布此版本之前进行功能冻结，通常持续六周。在此期间，仅应进行错误修复和文档工作。
在功能冻结前几周，可以选择进行规范冻结。
在功能冻结期结束后，将从 master 分支派生出一个稳定分支，并开始发布候选期。在此期间修复的 master 上的关键错误可能会回移植到稳定分支以供最终发布。
在迭代发布候选版本约四周后，最终版本将发布。此稳定版本可能会在较长时间（9-15 个月）内接收关键错误修复。
这种模式会产生一些问题。主要问题是开发发生在高峰和低谷。开发人员和供应商意识到功能冻结即将到来，并试图在冻结之前快速合并功能。这会产生大量的补丁和审查，这往往会使核心审查人员精疲力尽。然后功能冻结开始。无法着陆功能，开发几乎停止。这通常需要六周。一旦下一个周期开放用于功能开发，代码开始逐渐出现，但大多数人都在计划峰会并从上次发布的压力中休息。这实际上会导致每个周期开发者停工10 周，或每年 20/52 周。
提议的变更¶
我们应该按照 OpenStack 治理中定义的独立发布模型（大致）发布 Ironic。[2]
注意
截至 2015 年 7 月 15 日 [10]，ironic 遵循带有中间版本的周期发布模型 [11]。该模型与本规范更匹配，是在本规范获得批准后由 OpenStack 治理创建的。
这里有几点值得注意。
我们应该在 master 分支上完成主要功能或错误修复时发布 Ironic。这将由 Ironic 的 PTL 或指定的发布经理自行决定。
我们应该继续每六个月发布一个“最终”版本，以继续参与协调发布。[3]
作为功能冻结的替代方案，Ironic 的“稳定”版本应该来自一个“正常”的 Ironic 发布，该发布发生在其他集成项目开始发布候选期的时间点附近。例如，对于 Liberty[4]，Ironic 应该力争在九月的下半月发布一个版本。这将等同于 stable/liberty 分支。应该从该分支构建发布候选版本，并且可以接收错误修复。稳定版本应该有资格接收当前流程中的回移植。
Ironic 发布应该大致遵循 SemVer[5]——区别在于，当 Ironic 的功能或代码发生重大变化时，应该增加主版本号。Ironic 永远不应该在没有从先前版本升级路径的情况下发布版本，因此在传统的 SemVer 中，主版本号永远不会改变。我们应该根据需要增加次版本号和补丁版本号，以进行次要功能和错误修复发布。
Ironic 发布应该发布到 PyPI。
规范不再应该针对特定版本——人们应该持续地进行规范和代码工作。功能将随着着陆而发布。ironic-specs 仓库应该更改为
一个“approved”（已批准）目录，所有规范最初都位于其中。
单独的 $version-implemented 目录，其中包含在 Ironic 的 $version 版本中实现过的规范。当工作完成时，规范将被移动到此目录。
在旧位置创建一个占位符，指示工作是在 Ironic 的哪个版本中完成的，并链接到新位置。这将防止旧链接中断。
在所有发布之前，审查人员应该遵守为期几天到一周的“软冻结”期。在此期间，可能存在破坏风险的代码可能不应着陆；快速错误修复、驱动程序更改和其他风险较低的更改在大多数情况下都可以着陆。PTL 或指定的发布经理必须确保充分沟通即将发布的版本和这些冻结。
Ironic 可能需要在 Dep Freeze[7] 期间从全局要求中分离出来。在 OpenStack 的功能冻结期间，global-requirements 的 master 分支被锁定。接受对 master 分支上 ironic 的 requirements.txt 的更改是可以的，这些更改被 Dep Freeze 阻止在 global-requirements 中，因为稳定分支此时已经切断。这应该仅在问题出现时按需发生；而不是默认情况。我们可能还需要在此期间临时删除“gate-ironic-requirements”作业。最后，对 Ironic 更改 requirements.txt 的任何补丁也应该有一个补丁到 global-requirements，并得到 global-requirements 核心审查人员的一般“看起来不错”的反馈。
人们讨论过对较大的工作块使用功能分支。虽然这些可能很有用，但我们必须确保仅在绝对必要时才使用它们，因为功能分支可能会带来大量的痛苦。在可能的情况下，我们应该优先使用功能标志[9]而不是功能分支。
备选方案¶
继续现状。:(
数据模型影响¶
无。
状态机影响¶
无。
REST API 影响¶
无。
客户端 (CLI) 影响¶
没有。客户端将继续独立发布，并且可能比服务器更频繁地发布。
RPC API 影响¶
无。
驱动程序 API 影响¶
无。
Nova 驱动程序影响¶
由于 Nova 驱动程序与 Nova 一起发布，因此它的发布方式不会改变。
安全影响¶
由于只有稳定版本才会接收回移植，因此其他版本中的安全错误应该尽快修复并发布。应该发布一个建议，鼓励用户升级到新版本。
稳定分支将继续接收安全错误修复的回移植。
中间版本将不会接收安全补丁的回移植。中间版本中的任何安全错误都应该修复并发布到适当的版本更新。版本更改是主要/次要/补丁，可能取决于 master 上着陆并与补丁一起发布的内容。
其他最终用户影响¶
最终用户将更快地获得已发布的功能。
可扩展性影响¶
无。
性能影响¶
无。
其他部署者影响¶
部署者将更快地获得更改和功能。那些不想这样做的人可以继续使用每六个月的集成发布。
开发人员影响¶
所有的生产力。
实现¶
负责人¶
PTL、指定的发布经理（如果存在）和核心审查人员。
工作项¶
切换到 semver。
开始独立发布。
在开发者文档中记录该过程。[8]
依赖项¶
无。
测试¶
无。
升级和向后兼容性¶
这将导致升级更小，从而影响更小。
文档影响¶
我们应该在我们的开发者文档中编写一个关于该过程的页面，包括规范过程的更改。
参考资料¶
[0] https://etherpad.openstack.org/p/liberty-ironic-scaling-the-dev-team
[1] https://governance.openstack.org/tc/reference/tags/release_at-6mo-cycle-end.html
[2] https://governance.openstack.org/tc/reference/tags/release_independent.html
[3] https://governance.openstack.org/tc/reference/tags/integrated-release.html
[4] https://wiki.openstack.org/wiki/Liberty_Release_Schedule
[6] http://lists.openstack.org/pipermail/openstack-dev/2015-May/065211.html
[7] https://wiki.openstack.org/wiki/DepFreeze
[8] https://docs.openstack.org/developer/ironic/
[9] https://en.wikipedia.org/wiki/Feature_toggle
[10] https://review.openstack.org/#/c/202208/
[11] http://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html
