Spring 改变版本号命名规则：此举对非英语国家很友好

关注
发布于: 2020 年 11 月 16 日
要想改变命运，首先改变自己。本文已被 https://www.yourbatman.cn 收录，里面一并有Spring技术栈、MyBatis、JVM、中间件等小而美的专栏供以免费学习。关注公众号【BAT的乌托邦】逐个击破，深入掌握，
﻿
✍前言你好，我是YourBatman。
﻿
还记得在今年5月份样子看到了一篇来自Pivotal的邮件，大致内容是说Spring改变了版本号的命名规则，当时本着先收藏一下准备晚上再看，然后，就没有然后了。
﻿
直到前些天突然看到了篇标题为：Spring Data 2020.0.0正式发布的文章，这才让我把此事联想了起来，因此才决定写此文记录一下，顺带分享给你。
若你已苦于Spring Cloud的版本号命名方式，那么本文给你带来了曙光
﻿
﻿
✍正文天下苦Spring Cloud版本命名久矣。在正式开始之前，管生管养的A哥有意对这其中的相关名词进行解释，方便理解本文。
﻿
Release TrainRelease Train直译过来意思为：发版火车/火车发版。火车大家不陌生，它有一个显著的特点：定时定点发车。这里的发车在软件领域就等同于软件的发版。
﻿
为何需要Release Train发版模式？在公司还很小很小的时候，整个公司可能只有一个软件，版本发布非常的简单，没什么需要协调的，发就完了。但是，一旦公司快速发展变得比较大后，核心产品功能数以十、百计，各功能模块由不同的团队负责，沟通成本明显升高，单单在版本上稍不注意就会产生各种问题，很容易给人一种“乱如麻”的感觉。
﻿
使用Release Train的发版模式就能很大程度上避免这些问题，可以这样做：规定每个月的最后一天（精确的发版日期）需要发一版（类比于火车发车），那么就可以以这个时间点为deadline，参与的的各方包括产品经理、RD、QA等等都提前沟通好需求内容，并做好计划，充分做好统一发车的准备。在这期间，如果中间某一团队出现问题跟不上节奏了，那么请及时下车（前提是控制好下车的影响面），不要影响整体发车时间点。
﻿
总的来讲：火车是按点准时出发的，各方应按点上车，倘若本次赶不上车的那么就请等下一趟车。通过这种方式可以确保软件产品的持续迭代，保证产品的稳定性，这就是Release Train发版模式。
﻿
在实际的软件产品中，可以认为稍微大一点的软件都是按照此模式来持续迭代的，比如IOS、maxOS、MIUI、Spring Cloud等等。这些软件版本在命名方式上不同但均遵循一定规律：
IOS 14、IOS 14.1、IOS14.1.1
macOS Mojave、macOS Sierra
Spring Cloud Greenwich、Spring Cloud Hoxton
﻿
Project Module如果说按照Release Train发版模式发出的一个版本代表着一个大的产品版本号，那么Project Module就代表其内部的模块。一般一个软件产品由N多个模块组成，以最新的Spring Data 2020.0.0版本为例，内含有多个Project Module模块：
Spring Data Commons 2.4
Spring Data JDBC 2.1
Spring Data JPA 2.4
Spring Data MongoDB 3.1
Spring Data KeyValue 2.4
Spring Data LDAP 2.4
Spring Data Elasticsearch 4.1
...
﻿
Semantic Versioning语义化版本号，有被称作语义化版本控制规范，简称“SemVer”。它是一套版本号规则的标准/规范，用于改善软件版本号格式混乱问题，顺便统一一下版本号所表达的含义。官方主页是：https://semver.org
﻿
版本号组成SemVer版本号主要由三个部分组成，每个部分是一个非负整数，部分和部分之间用.分隔：主版本号.次版本号.修订号（简写为x.y.z）。下面对这三部分做出解释（约定）：
主版本号：只有进行非向下兼容的修改或者颠覆性的更新时，主版本号加1
	- 话外音：改变很大，暴力式更改
次版本号：进行向下兼容的修改或者添加兼容性的新功能时，次版本号加1
	- 话外音：改变不很大，一般是向下兼容的。值得注意的是：这里指的是一般，有些情况也存在不兼容情况也是允许的，当然不能是主要功能不兼容
补丁号：没有新功能加入，一般修复bug、优化代码等，补丁号加1
	- 话外音：此版本号可放心无缝升级
﻿
关于这三部分还有两点值得注意：
版本号均从0开始（包括主版本号）
	1. 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版
	2. 1.0.0 的版本号用于界定公共 API 的形成。也就说从
当主版本号更新时，次版本号和补丁号都要归零；次版本号更新时补丁号归零
﻿
版本号比较这种三段式的版本号是可以比较大小的。比较的顺序是：主版本号、次版本号、补丁号。举例：4.3.0 < 5.0.0 < 5.0.3 < 5.1.0
说明：使用.分隔开的话，正常比较（当字符串比较）是不会出现形如.2. > .10.的问题的
﻿
值得注意的是，Semantic Versioning只是一个标准，它并没有提供实现（比如版本号比较），虽然按照此规则自己实现一个并不复杂，但我建议各位不要自己实现，毕竟这种轮子社区里大把的，各种语言的都有哦，何必重复造呢。
﻿
Calendar Versioning日历化版本，简称CalVer。CalVer不是基于任意数字，而是基于项目发布日期的版本控制约定。相较于语义化版本号，日历化版本号更接地气，显得活力更强些。因为日期是单向向前的，因此版本随着时间的推移会变得更好。
﻿
方案类别有多种日历化版本方案，长期被各种大小项目使用。对于CalVer来说，它的规范非常抽象，毕竟发布日期本就是一个很抽象的概念嘛。
﻿
CalVer 并未像 “语义化版本” 那样选择单一方案， 而是引入了开发人员的 标准术语：
YYYY：年份全称。如：2020
YY：年费缩写。如：20
MM：月份缩写。如：1、2、3
DD：日缩写。如：1、2、3
...
﻿
和日期格式化类似有木有。是的，日期你可以随意，甚至可以是任意递增格式，但建议使用标准格式而已。
﻿
Spring改变版本号命名规则Spring团队在其官网博客里于2020-04-30对外宣布要改变版本号命名规则，共包含两部分的内容：
Release Train版本规则改变
Project Module版本规则改变
﻿
这些改变将在下一个发布版本里体现出来，比如我们已经能看到的使用新规则命名版本号的是：Spring Data 2020.0.0、Spring Data 2020.0.1
﻿
Release Train版本规则改变Spring自2013年以来一直按照字母表顺序来进行排序版本。举例两个典型的，也是我们比较熟悉的按照Release Train发版的项目给你瞧一瞧，我绘制成图标如下：
﻿
Spring Data：
﻿
 Release Train   | 发布日期
-------- | -----
Spring Data Arora | 2013-02
Spring Data Babbage | 2013-09
Spring Data Codd | 2014-02
Spring Data Dijkstra | 2014-05
... | ...
Spring Data Neumann | 2020-05
Spring Data 2020.0.0 | 2020-10
﻿
Spring Cloud：
﻿
 Release Train   | 发布日期
-------- | -----
Spring Cloud Angel | 2015-06
Spring Cloud Brixton | 2016-05
Spring Cloud Camden | 2016-09
Spring Cloud Dalston | 2017-04
... | ...
Spring Cloud Hoxton | 2019-11
Spring Cloud 2020.0.0-M4 | 2020-10
﻿
﻿
注意：截止目前，Spring Cloud 2020的正式版还未正式发布，预计11月结束之前会正式推出，以支持Spring Boot 2.4.0
﻿
存在的问题如上表所示，按照字母表排序作为版本号是存在如下问题的：
按照字母排序，对于非英文国家有一定门槛难以记忆（比如天朝的程序员们）
如果排序字母到达Z了，就会出现命名上的难题了
从版本号上不能体现出向下兼容性，着让使用者（准备升级者）很难做出判断而做出风险预估
单词的拼写很困难（版本号都得靠复制，现在是降低效率的表现）
﻿
解决问题（改变后）为了解决这些问题，Spring采用了日历化版本，并且使用的规则/公式是YYYY.MINOR.MICRO[-MODIFIER]，对各部分解释如下：
YYYY：年份全称。eg：2020
MINOR：辅助版本号（一般升级些非主线功能），在当前年内从0递增
MICRO：补丁版本号（一般修复些bug），在当前年内从0递增
MODIFIER：非必填。后缀，它用于修饰一些关键节点，用这些字母表示 
	- M数字：里程碑版本，如2020.0.0-M1、2020.0.0-M2
	- RC数字：发布候选版本，如2020.0.0-RC1、2020.0.0-RC2
	- SNAPSHOT：快照版本（后无数字哦），如2020.0.0-SNAPSHOT
	- 啥都木有：正式版本（可放心使用，相当于之前的xxx-RELEASE），如2020.0.0
﻿
通过新的版本命名方式，解决了向后兼容带来的问题（一看版本号就能清晰的知道向后兼容性如何），不再存在上限焦虑了，并且这种排序对非英语国家非常友好，点赞。
自此，对于Spring Cloud来说H版是它最后一个用英文单词命名的版本号了，下个版本将是Spring Cloud 2020.0.0，预计在本月正式发布。
﻿
Project Module版本规则改变对于项目模块的版本号而言，其实Spring早在其3.0.0.M1版本（2008年）就使用了“语义化版本”规则进行发布管理。本可以不用做改动也行，但Spring官方觉得既然这次对Release Train做了修整，那就一起调整下是更好的。
﻿
项目模块的版本规则Spirng采用Semantic Versioning语义版本号规范，另外呢Spring还希望开发者很容易熟悉这个版本号，因此制定了这个模版：MAJOR.MINOR.PATCH[-MODIFIER]。前面三部分就不再解释啦，详情请看上面的关于Semantic Versioning的说明。对于最后面的MODIFIER部分保持了和Release Train一模一样的语义：
MODIFIER：非必填。后缀，它用于修饰一些关键节点，用这些字母表示 
	- M数字：里程碑版本，如2.4.0-M1、2.4.0-M2
	- RC数字：发布候选版本，如2.4.0-RC1、2.4.0-RC2
	- SNAPSHOT：快照版本（后无数字哦），如2.4.0-SNAPSHOT
	- 啥都木有：正式版本（可放心使用，相当于之前的xxx-RELEASE），如2.4.0
﻿
总的来说此部分规则改变并不大，简单对比就是这样：
改变前     | 改变后
-------- | -----
3.0.0.M1  | 3.0.0-M1
﻿
以最新发布的Spirng Framework版本为例，它应用了最新的发版规则：
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>5.3.0</version>
    <!-- 5.2.0.RELEASE -->
</dependency>
对比新旧版本号可知，新规则最大的区别是干掉了 .RELEASE，因此书写时请稍加注意。
﻿
✍总结本次Spring做出版本号规则的调整，更加彰显活力。喜闻乐见的是这名称对于处于天朝的我们是利好啊，毕竟SC的那些英文单词你能记住几个？现在书写其版本号终于可以盲写了，并且通过版本号能非常直观的知晓到当前使用版本的新旧程度，从而做出相关判断/预估，非常便捷。
﻿
另外，截止稿前，Spring Boot 2.4.0（注意木有.RELEASE了哦）以及Spring Framework 5.3.0均已重磅发布，为了给马上到来的Spring Cloud 2020.0.0做好铺垫，接下来几篇文章将对它俩进行阐述，欢迎持续关注。
﻿
✔推荐阅读：JDK15正式发布，划时代的ZGC同时宣布转正
IntelliJ IDEA 2020.2正式发布，诸多亮点总有几款能助你提效
Spring Boot 2.3.0正式发布：优雅停机、配置文件位置通配符新特性一览
搞事情？Spring Boot今天一口气发布三个版本
﻿
﻿