本次反馈征集将在接下来的 4 周内开放，直至 9 月 7 日。
我提出了一种协调将新 API 从Gutenberg 插件合并到 WordPress核心的过程的方法。目前，这两个项目的政策截然不同，让贡献者感到困惑，并在每个主要的 WordPress 版本上引发了热烈的讨论。
今天，实验性 API 被合并到 Core 中，有时稍后会被删除
迄今为止，有 280 个实验性 API 从 Gutenberg 插件合并到 WordPress Core。这是有问题的，这就是原因。
WordPress 重视向后兼容性。升级到新版本不应破坏插件和主题，因此这些插件和主题所依赖的 WordPress 公共 API 在主要版本之间进行维护。正如WordPress 手册所述：
从历史上看，WordPress 以保持跨版本的向后兼容性而闻名。
Gutenberg 插件重视敏捷性。这是一个安全的空间，新的实验被种植并成长为没有相同稳定性约束的稳定特征。可以交付原型，从中学习，然后重新开始。正在积极开发的新功能通常在其名称中包含 __experimental 前缀，以表明它们可能随时更改且不应依赖。删除过时的代码还可以使JavaScript包更小，并减少编辑器加载时间。正如古腾堡插件手册所述：
实验性和不稳定的 API 是从模块中导出的临时值，这些值的存在要么等待未来的修订，要么提供立即结束的方法。
在 Gutenberg 插件中，可以删除这些实验性 API。在 WordPress 中，它不是。不幸的是，许多已经发布了主要的 WordPress 版本。
明天，实验性 API 可能仅限于 Gutenberg 插件，并且永远不会合并到 Core
让我们在将新 API 合并到 WordPress Core 之前删除实验性前缀。
这边走：
核心可以提供预期的向后兼容性水平
Gutenberg 插件可以保留根据需要删除实验性 API 的自由
实验性 API 将获得审核
这将使发布更容易
如果一个稳定的特性依赖于一个实验特性怎么办？
然后它实际上并不稳定。让我们首先稳定依赖关系。
现有的实验性 API 怎么样？
大多数已经合并到 Core 的人将获得一个稳定的别名。它将保留 BC，并且不会显着影响捆绑包的大小。有些人需要不同的治疗；让我们逐案讨论。
如果需要删除 Core 中已有的现有实验性API怎么办？
我们要不要？如果是这样，让我们逐案考虑。有既定的核心实践，如联系插件作者、撰写核心帖子、首选软弃用等等。我不希望看到很多这样的例子。
如果未来稳定的 Gutenberg 插件 API在 Core 中发布后真的需要删除怎么办？
是的，它会发生。让我们承认并接受它。GitHub 讨论中提到了一些很好的理由，未来会有许多新的理由让我们感到惊讶。同样，让我们遵循既定的核心实践。例如，deprecated.php表明删除函数体有时是可以的，只要名称继续有效。
有什么缺点？
我可以看到两个：
一些 Gutenberg 插件功能将在以后合并到 Core 中，就像它们目前那样。开发工作的总量不会改变，但合并时间表会改变。那可能是件好事。使用 Gutenberg 插件是提前访问即将推出的功能的预期方式。
一旦与 Core 一起发布，重构 Gutenberg 插件 API 将变得很困难。实际上，情况已经如此。
如果您发现任何其他缺点，请说出来！
考虑了哪些替代方案？
继续不对问题采取行动。
对 WordPress 和 Gutenberg 插件使用相同的向后兼容性策略——这会使这两个项目变得更糟。
找到一种方法将带有 Core 的实验性 API 作为“内部”并且对插件作者不可用 – 已经尝试过但没有得到太大的牵引力。
不幸的是，这两种方法都不可行，正如 GitHub 讨论中更详细解释的那样。
如果这引起您的共鸣，请在 9 月 7 日之前说出来！
