Spring团队已决定更改发布系列和项目模块的版本控制方案。这些更改将在下一个发布系列以及每个项目的次要版本中发布。实际上，这些更改已经存在于Spring Cloud 2020.0.0-M1中。Maven和Gradle没有提供完全相同的版本排序，但是我们正在与Gradle团队合作，以确保使用两种工具以相同的方式对Spring方案进行排序。
发布火车版本更改
自2013年以来，Spring一直使用按字母顺序排列的主题发行火车版本。发行火车包含一组可以很好地协同工作的项目版本，但不能保证升级到下一个发行火车时基础库的向后兼容性。
从那时起，社区就对版本名称提出了一些担忧，我们一直在倾听。一个主要的问题是该计划对于非英语母语者按字母顺序排序可能会带来挑战。此外，主题名称可能难以记住版本名称。最后，某些主题名称可能很难拼写。
为了解决这些问题，Spring团队决定使用的方案切换到Calendar Versioning（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，等。