Library Version Compatibility

Spartacus 项目由一组库组成。为了更容易知道哪个版本的库与另一个版本兼容，库版本在所有包之间同步。这意味着当我们要发布 1.5.0 版本时，我们会发布此版本下的所有库，即使某些库自上一版本以来没有任何更改。这样做时，我们可以使用单个版本号来引用任何给定版本的整个 Spartacus 库集。

这也意味着您可以确信，如果您安装所有具有相同版本的软件包，那么一切都将正常工作。不同版本的库可以很好地协同工作，但我们不会测试这些配置，也不能保证正确的行为。

version support

对于版本控制，我们遵循语义版本控制，也称为 SemVer。除了稳定版本，Spartacus 还生产 next 和 rc 版本。

我们对版本的假设如下：

Stable 版本是经过良好测试的 Spartacus 版本（包括社区测试），并且只会修补错误。这些版本在 npm 上的最新标签下可用。
当 Spartacus 团队完成该版本所有新功能的开发后，就会发布一个 rc 版本，这意味着功能和公共 API 不会有任何重大变化。社区可以安全地开始测试 rc 版本中的功能。 rc 版本可能包含一些错误，这些错误将在稳定版本发布之前修复。当没有更多错误并且社区停止报告该版本的问题时，我们会继续制作稳定版本。
当 Spartacus 团队完成特定功能时，将发布一个 next 版本。这允许社区立即开始测试该功能。这些 next 版本可能包含很多错误，功能和公共 API 可能仍会发生变化。如果您想尽快测试新功能，这是适合您的版本。下一个版本在 npm 上的 next 标签下可用。

注意：强烈建议您不要在生产设置中使用 next 版本。这是因为从next 版本升级可能比从一个稳定版本升级到另一个要困难得多。

始终支持至少一个稳定或 rc 版本。

一旦版本 x.y 发布，它将被积极维护，直到版本 x.z 的新稳定版或 rc 发布。届时，版本 x.z 将成为积极维护的版本，下一个版本的工作将开始。

例如，假设我们刚刚发布了 1.5.0-rc.0 版本。从那时起，将积极维护 1.5.x 版本，直到我们发布 1.6.0-rc.0。一旦 1.6.0-rc.0 版本发布，我们就会将主动支持切换到 1.6.x 版本。

注意：对于重要的安全问题或关键的错误修复，可能会有针对不再积极维护的版本的附加补丁。

Spartacus 项目中的流程围绕前面部分中描述的版本支持构建。

develop 分支是默认分支，用于新版本开发，包括次要和主要版本。所有功能和错误修复都合并到这个分支。

还有一个 maintenance 分支，它随着新的稳定版或 rc 版本而变化，用于补丁版本。只有错误修复合并到 maintenance 分支。

一旦我们发布了 1.4.0-rc.0 版本，release/1.4.x 分支将被视为维护分支。当我们发布 1.5.0-rc.0 版本时，则 release/1.5.x 分支成为维护分支，依此类推。

其他分支约定：

以下是处理错误修复的步骤：

以下是我们目前使用的可能会产生误导的术语：

“feature freeze” 描述了我们完成了新的次要或主要版本的所有功能的那一刻（这意味着我们希望很快发布一个 rc，但仍需要修复一些错误）。

“code freeze” 描述了我们停止提交代码的那一刻（尽管这在我们的流程中不是必需的，因为我们总是可以切断发布或维护分支并继续提交）。

以下概念可用于替换这些术语：

我们可以创建一个新的维护分支并发布一个新的 rc。第一个 RC 可能有问题，因为 rc 版本可能包含错误是公认的。

我们可以创建一个新的 release 分支，而不是冻结代码。我们永远不需要阻塞主要的开发或维护分支（我们不需要用这些细节来打扰开发人员，因为我们的流程支持在这些分支上并发工作并发布另一个版本）。

maintenance 分支是需要合并到release/xxx的东西

示例：你合并了一些东西来开发，但它需要在 4.0.1 中或者也需要向后移植到另一个旧的发布分支，然后你需要创建一个 PR 来将它合并到 release/4.0.x 。

通常，新功能维护分支最终是 feature/GH-xxx-maintenance 并将合并到 release/xxx 而不是 develop。