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

用户头像
YourBatman
关注
发布于: 2020 年 11 月 16 日
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发版模式?

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



使用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

- 话外音:此版本号可放心无缝升级



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

  1. 版本号均从0开始(包括主版本号)

1. 主版本号为零(0.y.z)的软件处于开发初始阶段,一切都可能随时被改变。这样的公共 API 不应该被视为稳定版

2. 1.0.0 的版本号用于界定公共 API 的形成。也就说从

  1. 当主版本号更新时,次版本号和补丁号都要归零;次版本号更新时补丁号归零



版本号比较

这种三段式的版本号是可以比较大小的。比较的顺序是:主版本号、次版本号、补丁号。举例: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对外宣布要改变版本号命名规则,共包含两部分的内容:

  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-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做好铺垫,接下来几篇文章将对它俩进行阐述,欢迎持续关注。



✔推荐阅读:





发布于: 2020 年 11 月 16 日 阅读数: 1003
用户头像

YourBatman

关注

公众号:BAT的乌托邦 2018.01.21 加入

专注Java领域分享、成长,拒绝浅尝辄止。公众号搜索:BAT的乌托邦。CSDN博客之星Top10

评论

发布
暂无评论
Spring改变版本号命名规则:此举对非英语国家很友好