02. Spring版本命名规范

Posted 2021-05-14 IT BOY

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了02. Spring版本命名规范相关的知识，希望对你有一定的参考价值。

02. Spring版本命名规范

Pt1 Semantic Versioning 2.0.0

02. Spring版本命名规范

无论是Jar包还是服务，越来越多都是基于版本号来发布。我现在的公司里，项目中的版本命名风格各异，或者可以理解为很混乱，拿到别人的Maven坐标都不知道是beta版本、测试版本还是最终版本，很多人用snapshot做生产版本。所以，统一的版本命名规范非常重要，学习Spring的版本命名规范，可以作为日后项目中的参考，避免使用一些诡异的命名规则闹出笑话。

用过Maven组件的都知道版本号的概念，实际上不同软件的版本号风格各异，差异也比较大。

Linux Kernel版本号有0.0.1、1.0.0、2.6.32等，可以用X.Y.Z的形式表示。其中偶数Y表示稳定版本，奇数Y表示开发版本。
Windows版本都很熟了，有Windows2000、Windows XP、Windows7，几乎毫无规律。
OpenStack是形如2014.1.3、2015.1.1.dev8这种有日期标识的形式。

不同软件厂商可以根据自身风格来定义自身的版本号规范，但是对于使用者来说，随着系统的规模增大，依赖的软件越来越多，如果所有软件都有自身一套特异的版本命名规范，这无疑会成为一种灾难（Dependency Hell）。所以Github有人提出了标准统一的语义化版本规范Semantic Versioning，通过一套简单的规则及条件来约束版本号的配置和增长。

Pt1 Semantic Versioning 2.0.0

英文官方：https://semver.org/

中文官方：https://semver.org/lang/zh-CN/

以上是官方给出的详细资料，下面针对规范做简单的整理。

Pt1.1 摘要

命名规范：主版本号.次版本号.修订号(Major.Minor.Patch，又称X.Y.Z）。

版本号递增规则说明如下：

主版本号：当你做了不兼容的 API 修改，需要递增。
次版本号：当你做了向下兼容（不影响API兼容性）的功能性新增，需要递增。
修订号：当你做了向下兼容（不影响API兼容性）的问题修复，需要递增。
先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。这个后面有例子。

Pt1.2 规范

以下关键词 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照 RFC 2119 的叙述解读。

使用语义化版本控制的软件必须（MUST）定义公共 API。该 API 可以在代码中被定义或出现于严谨的文件内。无论何种形式都应该力求精确且完整。
标准的版本号必须（MUST）采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止（MUST NOT）在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须（MUST）以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
标记版本号的软件发行后，禁止（MUST NOT）改变该版本软件的内容。任何修改都必须（MUST）以新版本发行。
主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。
1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。
修订号 Z（x.y.Z | x > 0）必须（MUST）在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。
次版本号 Y（x.Y.z | x > 0）必须（MUST）在有向下兼容的新功能出现时递增。在任何公共 API 的功能被标记为弃用时也必须（MUST）递增。也可以（MAY）在内部程序有大量新功能或改进被加入时递增，其中可以（MAY）包括修订级别的改变。每当次版本号递增时，修订号必须（MUST）归零。
主版本号 X（X.y.z | X > 0）必须（MUST）在有任何不兼容的修改被加入公共 API 时递增。其中可以（MAY）包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号必须（MUST）归零。
先行版本号可以（MAY）被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。数字型的标识符禁止（MUST NOT）在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。
版本编译元数据可以（MAY）被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符来修饰。标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白。当判断版本的优先层级时，版本编译元数据可（SHOULD）被忽略。因此当两个版本只有在版本编译元数据有差别时，属于相同的优先层级。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。
版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须（MUST）把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较（版本编译元数据不在这份比较的列表中）。由左到右依序比较每个标识符，第一个差异值用来决定优先层级：主版本号、次版本号及修订号以数值比较，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时，改以优先层级比较低的先行版本号决定。例如：1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号，其优先层级必须（MUST）透过由左到右的每个被句点分隔的标识符来比较，直到找到一个差异值后决定：只有数字的标识符以数值高低比较，有字母或连接号时则逐字以 ASCII 的排序来比较。数字的标识符比非数字的标识符优先层级低。若开头的标识符都相同时，栏位比较多的先行版本号优先层级比较高。范例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。