版本控制策略

CKEditor 5 包含多个 npm 包（超过 80 个）。在发布它们时，我们使用以下规则

• 我们使用 MAJOR.MINOR.PATCH 版本标识符。
• 所有包始终处于同一版本。
• 当至少一个 CKEditor 5 包（即所有包）必须进行重大版本发布时，就会发布 CKEditor 5 的重大版本。
• 当至少一个 CKEditor 5 包（即所有包）必须进行次要版本发布，而没有一个包需要进行重大版本发布时，就会发布 CKEditor 5 的次要版本。
• 当一个包包含重大更改时，该包必须进行重大版本发布。
• 如果所有包都不包含任何重大更改，则使用以下规则确定每个包的新版本
  • 如果一个包包含次要更改，则会增加MINOR 版本。
  • 如果一个包包含新功能，则会增加MINOR 版本。
  • 如果一个包仅包含错误修复、无关更改（例如更新的翻译）、文档或其他内部更改，则会增加PATCH 版本。
• 为了确保所有包都处于同一版本，某些包的某些版本可能是空的（没有更改）。

# 重大更改和次要的重大更改

CKEditor 5 的生态系统包含多个层级。我们对重大更改及其影响的方式取决于哪个层级受到影响。

• 集成层级。 这是最常用的 API，用于集成和自定义现有构建或从源代码构建的编辑器。它还包括其设置（包含的功能及其默认配置）。
  • 重大更改频率：尽可能减少。因此，对该层级的更改通常以向后兼容的方式完成。
  • 该层级中的重大更改被理解为重大更改。
• 插件开发 API 层级。 这是由诸如 @ckeditor/ckeditor5-engine 或 @ckeditor/ckeditor5-core 等包公开的 API，插件开发人员通常会使用它。
  • 重大更改频率：很少。该层级仍被开发人员频繁使用，因此，我们试图限制重大更改。但是，为了避免增加技术债务，我们有时会对一个或多个包引入重大更改。我们也尝试将它们“打包”，以便尽可能在一个版本中完成尽可能多的重大更改，以降低重大版本发布的频率。
  • 该层级中的重大更改被理解为重大更改。
• 低级可定制 API 层级。 这是包 API 中允许调整现有功能的行为、其 UI 等以及在现有功能之上或使用其帮助程序构建其他功能的部分。
  • 重大更改频率：频繁。该层级虽然由 CKEditor 5 框架公开，但通常与某个功能的架构密切相关，并且可能会公开一些实现细节。我们希望该层级是公开的，因为它增加了代码重用能力，但是，我们无法保证其稳定性与前两个层级相同。
  • 该层级中的重大更改被理解为次要更改。

# 为什么不使用语义化版本控制？

在 15.0.0 版本之前，每个包都是独立版本化的，并遵循 语义化版本控制 (SemVer)。尽可能遵循 SemVer 非常有用，因为它使我们能够快速识别某个包的每个版本中的更改。但是，它导致了 构建编辑器旧版本的错误。

因此，我们切换到一个更常用的包生态系统实践，即将单个重大更改视为所有包的重大版本发布。它自动修复了上述所有在 package.json 文件中使用插入符号范围的项目中的问题。后来，我们决定，如果所有包都处于完全相同的版本，这对于集成者来说会更加方便，这也是并不罕见的做法（例如，Angular 遵循这种实践）。