昨日，Francesca Marano开启了换台推荐对于 WordPress 核心发布周期。这是一个于 2020 年 10 月启动的平台讨论区。目标是使平台的各个阶段与更大的开发行业标准保持一致。
撇开命名不谈，WordPress 在处理发布周期方面一直跟随软件行业。遵循众所周知的约定可以让 WordPress 生态系统之外的开发人员更容易过渡到它。它还将允许开发人员遵循其他项目的周期，其中许多是 WordPress 依赖项。在整个软件开发领域，这种标准化通常被视为一件好事。
根据自 10 月以来的持续讨论，就重命名阶段以符合标准达成了共识。下表显示了每个阶段将重命名为：
| 对应 | 当前名称 | 建议名称 |
|---|---|---|
| 1 | 规划和确保团队领导权 | 初步规划 |
| 2 | 开发工作开始 | Α |
| 3 | Beta | |
| 4 | 候选发布版 | 候选版本 |
| 5 | Launch | General Release |
不过，这是一个分为两部分的提案。简单地重命名阶段不会改变发布周期的工作方式。为了严格遵守这个标准，WordPress在提交代码的时候也需要进行修改。
Beta阶段如何处理
Beta阶段如何处理存在争议。除了在周期早期引入的新错误修复之外，该标准不需要更改其他代码。对于 WordPress 项目，这会产生问题。
WordPress 今年满 18 岁了。多年来积累了很多老bug。这些通常在周期的后期修复（有时在 Beta 中）。这些较旧的错误可能不在初始计划阶段，但这是否意味着它们应该等到下一个版本？严格按照提议，应该搁置。
它还强制冻结了该版本的所有增强功能，但这些增强功能是不完整的。
Josepha Haden 写道，“我担心我们不会为那些不是特定于发布中的计划功能的旧错误留出空间。”对原始讨论的评论。 “我还担心，通过在过程的早期调用硬冻结，我们正在大大缩小功能包含的窗口。我现在不喜欢将自己局限于特定的错误，因为那不包括我们的许多志愿贡献者。由于功能复杂且变化迅速，因此使用这些功能更加困难，而较旧的错误为临时贡献者提供了更多机会。”
另一方面，错误修复有可能引入新的，不可预见的错误。 Beta 中添加的越晚，在“一般发布”阶段之前发现此类错误的可能性就越小。等待下一个周期为测试提供了更多时间。
该系统的优点之一是在 Beta 测试期间几乎不会产生任何新错误。这将使志愿者能够将更多的精力集中在测试和修复 Alpha 中出现的问题上。
WordPress 总是在自己的架子上行走。它允许更严格地遵守标准，同时在项目有意义的情况下让您摆脱严格的限制。不适用于特定版本的 Beta 阶段错误修复可以根据具体情况进行处理。我们有处于领导地位的人，他们有能力在这些电话出现时发出通知。通过次要版本的自动更新，我不太担心后期错误。
Tonya Mork 针对缺陷工作提出了两种解决方案，以便在发布周期期间以及发布周期之前和之后继续进行。两者都要求 WordPress 处于 beta 分支，为贡献者提供一种推进和修复错误的方法。
第一个提案要求在 Beta 1 之前两到三周提前冻结功能。在 Alpha 阶段结束时，这段时间将用于缺陷工作。
第二个解决方案将此缺陷工作移至与先前版本的 Beta 和 Release Candidates 重叠。这允许在主要版本之间的时间继续工作。它还可能缩短整个主要发布周期。
第二种解决方案也符合 Joost de Valk 关于处理缺陷的想法。他谈到这些提议时说：“我认为我们应该早点扩展并保持主要线路对正常业务开放。”这样一切都将始终有效，但取决于您提交的时间，它不会包含在下一个版本中。好吧，我所知道的世界上每一个开源软件都像 WordPress 一样工作。
当更改在 Beta 或 Release Candidate 阶段下降时，许多插件和主题开发人员已经在努力跟上。清楚地划分变化领域将有利于扩展生态系统，从长远来看也将有助于最终用户。第二种解决方案可以做到这一点。
将两种解决方案结合起来没有错。由于该计划将在 Beta 阶段进行分支，因此第二个解决方案已通过分叉操作实施。真正的讨论是关于项目是否应在 alpha 阶段投入一些时间专门解决错误。
对该提案的评论将持续到 1 月 20 日，然后才能做出最终决定。
下一个建议：语义版本控制，有人吗？任何人？有这个东西吗？
像这样：
喜欢加载...
资源
