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