Spring 团队决定更改 发布列车 和 项目模块 的版本控制方案。这些更改将在下一个发布列车和每个项目的次要版本中进行。事实上，这些更改已存在于 Spring Cloud 2020.0.0-M1 中。Maven 和 Gradle 提供的版本排序并不完全相同，但我们正在与 Gradle 团队合作，以确保 Spring 方案最终能够在这两种工具中都以相同的方式排序。

发布列车版本更改

自 2013 年以来，Spring 一直使用按字母顺序排列的、主题化的 发布列车 版本。发布列车包含一组协同工作的项目版本，但在升级到下一个发布列车时，不保证底层库的向后兼容性。

从那时起，社区对版本名称提出了一些疑虑，我们也听取了这些意见。主要问题是，对于非英语母语人士来说，该方案可能难以按字母顺序排序。此外，主题名称可能难以记住版本名称。最后，一些主题名称可能难以拼写。

为了解决这些问题，Spring 团队决定切换到 日历版本控制 (calver)，使用 YYYY.MINOR.MICRO[-MODIFIER] 的方案，其中

• YYYY 是完整年份。

• MINOR 是每年递增的、以 0 为基数的数字。

• MICRO 是补丁版本。

• MODIFIER 是一个可选的修饰符，其中 <COUNT> 是一个递增的以 1 为基数的数字

  • 对于里程碑版本，我们将使用 M<COUNT>。

  • 对于候选版本，我们将使用 RC<COUNT>。

  • 对于快照版本，我们将使用 -SNAPSHOT。请注意，我们之前方案中存在的 .BUILD 已被删除。

  • 对于正式版本，将没有修饰符。

版本顺序示例为 2020.0.0-M1、2020.0.0-M2、2020.0.0-RC1、2020.0.0-SNAPSHOT、2020.0.0、2020.0.1-SNAPSHOT、2020.0.1、2020.1.0-M1、2020.1.0-M2、2020.1.0-RC1、2020.1.0-SNAPSHOT、2020.1.0 等。

这解决了对向后兼容性影响的担忧问题，简化了非英语母语人士的排序，比基于名称的版本更容易记住，并消除了拼写方面的挑战。与许多其他使用 calver 的项目一样，Spring 团队也可能会继续使用遵循旧约定版本的代号来指代每个列车。

项目模块版本更改

自 2008 年的 Spring Framework 3.0.0.M1 以来，Spring 团队一直使用与 OSGi 语义版本控制 兼容的相同版本。我们认为，既然我们正在重新审视发布列车版本控制方案，那么重新审视我们的项目模块版本也是一件好事。

虽然拥有与 OSGi 兼容的版本很方便，但对于 Maven 版本与 OSGi 兼容，则没有必要这样做，因为捆绑包元数据可以在其中指定与 OSGi 兼容的版本。我们决定新的版本控制方案将遵循 语义版本控制 中定义的语法，以帮助解析版本号。我们也希望我们的版本对 Java 开发人员来说很熟悉。鉴于上述信息，我们决定切换到 MAJOR.MINOR.PATCH[-MODIFIER] 的版本控制方案，其中

• MAJOR 如果递增，则可能需要大量工作才能升级。

• MINOR 如果递增，则升级工作量应该很少或没有。

• PATCH 如果递增，则不应需要任何工作。

• MODIFIER 是一个可选的修饰符，其中 <COUNT> 是一个递增的以 1 为基数的数字

  • 对于里程碑版本，我们将使用 M<COUNT>。

  • 对于候选版本，我们将使用 RC<COUNT>。

  • 对于快照版本，我们将使用 -SNAPSHOT。请注意，我们之前方案中存在的 .BUILD 已被删除。

  • 对于正式版本，将没有修饰符。

版本顺序示例为 2.3.0-M1、2.3.0-M2、2.3.0-RC1、2.3.0-RC2、2.3.0-SNAPSHOT、2.3.0、2.3.1-SNAPSHOT、2.3.1、2.4.0-M1、2.4.0-M2、2.4.0-RC1、2.4.0-SNAPSHOT、2.4.0 等。

结论

我们要感谢您，社区，感谢您的反馈，我们希望这些更改能改善您使用 Spring 的体验！