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

要想改变命运，首先改变本身。本文已被 https://www.yourbatman.cn 收录，里面一并有Spring技术栈、MyBatis、JVM、中间件等小而美的专栏供以避免费学习。关注公众号【BAT的乌托邦】逐个击破，深刻掌握，

✍前言

你好，我是YourBatman。

还记得在今年5月份样子看到了一篇来自Pivotal的邮件，大体内容是说Spring改变了版本号的命名规则，当时本着先收藏一下准备晚上再看，而后，就没有而后了。

直到前些天忽然看到了篇标题为：Spring Data 2020.0.0正式发布的文章，这才让我把此事联想了起来，所以才决定写此文记录一下，顺带分享给你。

若你已苦于Spring Cloud的版本号命名方式，那么本文给你带来了曙光

✍正文

天下苦Spring Cloud版本命名久矣。在正式开始以前，管生管养的A哥有意对这其中的相关名词进行解释，方便理解本文。

Release Train

Release Train直译过来意思为：发版火车/火车发版。火车你们不陌生，它有一个显著的特色：定时定点发车。这里的发车在软件领域就等同于软件的发版。

为什么须要Release Train发版模式？

在公司还很小很小的时候，整个公司可能只有一个软件，版本发布很是的简单，没什么须要协调的，发就完了。可是，一旦公司快速发展变得比较大后，核心产品功能数以10、百计，各功能模块由不一样的团队负责，沟通成本明显升高，单单在版本上稍不注意就会产生各类问题，很容易给人一种“乱如麻”的感受。

使用Release Train的发版模式就能很大程度上避免这些问题，能够这样作：规定每月的最后一天（精确的发版日期）须要发一版（类比于火车发车），那么就能够以这个时间点为deadline，参与的的各方包括产品经理、RD、QA等等都提早沟通好需求内容，并作好计划，充分作好统一发车的准备。在这期间，若是中间某一团队出现问题跟不上节奏了，那么请及时下车（前提是控制好下车的影响面），不要影响总体发车时间点。

总的来说：火车是按点准时出发的，各方应按点上车，假若本次赶不上车的那么就请等下一趟车。经过这种方式能够确保软件产品的持续迭代，保证产品的稳定性，这就是Release Train发版模式。

在实际的软件产品中，能够认为稍微大一点的软件都是按照此模式来持续迭代的，好比IOS、maxOS、MIUI、Spring Cloud等等。这些软件版本在命名方式上不一样但均遵循必定规律：

• IOS 1四、IOS 14.一、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”。它是一套版本号规则的标准/规范，用于改善软件版本号格式混乱问题，顺便统一一下版本号所表达的含义。官方主页是：semver.org

版本号组成

SemVer版本号主要由三个部分组成，每一个部分是一个非负整数，部分和部分之间用.分隔：主版本号.次版本号.修订号（简写为x.y.z）。下面对这三部分作出解释（约定）：

• 主版本号：只有进行非向下兼容的修改或者颠覆性的更新时，主版本号加1
  • 话外音：改变很大，暴力式更改
• 次版本号：进行向下兼容的修改或者添加兼容性的新功能时，次版本号加1
  • 话外音：改变不很大，通常是向下兼容的。值得注意的是：这里指的是通常，有些状况也存在不兼容状况也是容许的，固然不能是主要功能不兼容
• 补丁号：没有新功能加入，通常修复bug、优化代码等，补丁号加1
  • 话外音：此版本号可放心无缝升级

关于这三部分还有两点值得注意：

1. 版本号均从0开始（包括主版本号）
   1. 主版本号为零（0.y.z）的软件处于开发初始阶段，一切均可能随时被改变。这样的公共 API 不该该被视为稳定版
   2. 1.0.0 的版本号用于界定公共 API 的造成。也就说从
2. 当主版本号更新时，次版本号和补丁号都要归零；次版本号更新时补丁号归零

版本号比较

这种三段式的版本号是能够比较大小的。比较的顺序是：主版本号、次版本号、补丁号。举例：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：月份缩写。如：一、二、3
• DD：日缩写。如：一、二、3
• ...

和日期格式化相似有木有。是的，日期你能够随意，甚至能够是任意递增格式，但建议使用标准格式而已。

Spring改变版本号命名规则

Spring团队在其官网博客里于2020-04-30对外宣布要改变版本号命名规则，共包含两部分的内容：

1. Release Train版本规则改变
2. 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

存在的问题

如上表所示，按照字母表排序做为版本号是存在以下问题的：

1. 按照字母排序，对于非英文国家有必定门槛难以记忆（好比天朝的程序员们）
2. 若是排序字母到达Z了，就会出现命名上的难题了
3. 从版本号上不能体现出向下兼容性，着让使用者（准备升级者）很难作出判断而作出风险预估
4. 单词的拼写很困难（版本号都得靠复制，如今是下降效率的表现）

解决问题（改变后）

为了解决这些问题，Spring采用了日历化版本，而且使用的规则/公式是YYYY.MINOR.MICRO[-MODIFIER]，对各部分解释以下：

• YYYY：年份全称。eg：2020
• MINOR：辅助版本号（通常升级些非主线功能），在当前年内从0递增
• MICRO：补丁版本号（通常修复些bug），在当前年内从0递增
• MODIFIER：非必填。后缀，它用于修饰一些关键节点，用这些字母表示
  • M数字：里程碑版本，如2020.0.0-M一、2020.0.0-M2
  • RC数字：发布候选版本，如2020.0.0-RC一、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-M一、2.4.0-M2
  • RC数字：发布候选版本，如2.4.0-RC一、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今天一口气发布三个版本