Spring 团队决定更改发布列车（release train）和项目模块（project module）的版本控制方案。这些更改将在下一个发布列车以及每个项目的次要版本中推出。事实上，这些更改已经包含在Spring Cloud 2020.0.0-M1 中。Maven 和 Gradle 在版本排序上不完全一致，但我们正与 Gradle 团队合作，以确保 Spring 的方案在这两种工具中都能以相同的方式排序。

发布列车版本变更

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

从那时起，社区对版本名称提出了一些担忧，我们也听取了意见。主要担忧是，对于非英语母语者来说，按字母顺序排序这个方案可能会比较困难。此外，带有主题的名称可能难以记住版本名称。最后，一些主题名称可能难以拼写。

为了解决这些担忧，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 Semantic Versioning 兼容的版本。我们认为，既然我们正在重新审视发布列车的版本方案，那么也应该重新审视项目模块的版本。

虽然拥有 OSGi 兼容版本很方便，但 Maven 版本并不需要这样做也能与 OSGi 兼容，因为 bundle 元数据可以在其中指定一个 OSGi 兼容的版本。我们决定新的版本方案将遵循语义版本控制 (Semantic Versioning) 中定义的语法，以帮助解析版本号。我们也希望我们的版本能让 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 的体验！