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 版本升级可能比从一个稳定版本升级到另一个要困难得多。

Support Policy

始终支持至少一个稳定或 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 版本。

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

Git Flow

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

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

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

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

其他分支约定：

• feature/GH-xxxx 分支用于简单的功能和错误修复
• epic/epic-name 分支用于大特征（称为 epics）
• release/1.4.0-rc.0 分支用于特定的发布（你可以将它们与维护分支区分开来，因为包含完整的版本号）

Flow for Epic Development

• 从 develop 分支创建一个新的 epic/epic-name分支。

• 从epic/epic-name 为epic 子任务创建分支，并将它们合并回 epic/epic-name 分支。

• 不时地使用来自 develop 分支的更改更新您的 epic/epic-name 分支（它将帮助您管理冲突）。

• 当 epic 完成时，创建一个 PR 并将 epic/epic-name 分支合并到 develop 分支。

Flow for Smaller Features

• 从 develop 分支创建一个新的 feature /GH-xxxx 分支。

• 开发您的功能。

• 完成后，创建一个 PR 并将 feature/GH-xxxx 分支合并到 develop 分支。

错误修复流程

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

• 从开发分支创建一个新的 feature/GH-xxxx 分支。

• 修复错误。

• 创建 PR 并将 feature/GH-xxxx 分支合并到 develop 分支。

• 如果此修复适用于积极支持的版本，请从 maintenance 分支创建一个新的 feature/GH-xxxx-maintenance 分支。

• Cherry pick the commit with the fix from the develop branch.

• 创建 PR 并将 feature/GH-xxxx-maintenance 合并到 maintenance 分支中。

Terminology

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

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

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

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

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

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

term：维护分支，特性分支

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

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

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