maven的版本号version的总结及理解

本文目的

接上一篇，maven的基本概念介绍，大概了解maven里边的坐标、仓库的概念。其中，坐标里有版本号<version>这个标签，关于这个标签的作用，我觉得是非常的大，所以就单独总结了一下我对它的理解。
做Maven项目时，常常会听到周围的人说起版本这个东西，要做版本管理、要有版本迭代机制、要控制住版本！。
在这里插入图片描述
我觉得，包括我们公司在内的大部分软件公司，真正做到版本管理，还需要一些时间，当一个项目组不是在做产品交付，而是为了协助市场大区，快速交付项目的时候，很难控制版本，尤其是一个充满不同需求却又无法兼容的项目，搞的所有人心力憔悴。像这种开发模式下，我觉得它应该称为横向扩展的版本，做这种项目的是大部分公司，也是非常辛苦的。

往往这种情况，如果没有前期做到足够的调研，产品开发过程就直接对标第一个客户的需求，然后再基于后边大量的项目实践，才总结出来自己产品。当总结完产品之后，再回过头来，看自己以前设计的所谓产品，四个字，惨不忍睹。

原因是什么？从开发角度来看，那肯定是项目要的急、需求不明确。

以上问题怎么解决？我觉得普通公司很难。只能靠我们摆正应对的心态，我以前考虑过这个问题，后来我就理解这其中的几个冲突。

来自产品的冲突。产品不是开发，大部分不了解开发的工作模式，他们是理想主义者，而很多的开发缺乏产品一是，有的时候很难从客户角度考虑应用。所以，互相考虑，真的没必要搞得跟敌人一样，因为我们都有共同的目标。
来自社会风气的冲突。都知道天下熙熙，皆为利来，从领导层面来看，市场盘子就这么大，大家都不讲武德，谁更早点做出来，就更有可能赚到钱，更好的经营公司，我们作为公司的一员，就要在这种环境下，协助公司有所突破才是我们要做的。

这些冲突和现状，只能靠研发负责人来权衡并决断，我个人觉得，在一定程度上横向版本控制越少，会越好维护。
成长的过程总会令人煎熬。各位加油！以下内容，通过学习了《maven实战》，结合自己的理解，一起总结到这里的。

正文

1. 版本管理

说了那么多废话，什么是版本管理？首先，一个健康的项目，通常有一个长期、合理的版本演变过程。版本管理是指项目整体版本的演变过程管理，就比如从1.0-SNAPSHOT------1.0------1.1-SNAPSHOT----演变。体现的是从开发快照版到稳定版，继续升级进入下一个版本的快照开发版的过程。（SNAPSHOT叫快照版）
注意，版本控制与版本管理不同,版本控制是借助版本控制工具，追踪代码的每一次变更记录。

2. 版本号

2.1 版本号的组成

我们在引入其他依赖的时候，经常看到，比如1.2.1、1.7、1.0-SNAPSHOT、1.1-release、2.3-alpha等的version。但它们的组成比较简单，如下，maven的版本构成：

	<主版本>.<次版本>.<增量版本> - <里程碑版本>

一般情况下，主版本和次版本会一直存在，增量版本和里程碑版本见到的相对少的多。

主版本：表示项目的重大架构变化。如struts2和struts1采用不同的架构。

次版本：较大范围功能增加和变化，及bug修复，并且不涉及到架构变化的。

增量版本：表示重大bug的修复，如果发现项目发布之后，出现影响功能的bug，及时修复，则应该是增量版本的变化。

里程碑版本：往往表示某个版本的里程碑，经常见到snapshot，另外还有alpha、beta，比如：1.0-SNAPSHOT、3.0-alpha-1、1.1.2-beta-2。
在这里插入图片描述

2.2 snapshot介绍

通常在开发的阶段，你们会在maven项目的pom.xml里看到，当前项目的版本号后边带有SNAPSHOT,那它代表什么意思呢？用于什么场景？

snapshot表示快照版，它不是个稳定版本，属于开发过程中使用的版本。当我们项目处于不停的迭代开发期，如果存在依赖关系，比如A项目组开发后发布的新包，被B项目组引用，这时候使用快照版本snapshot，能够在A项目组发布到仓库后，自动转为最新时间戳的后缀，供B项目组自动引用成功。

这样的好处是，当我们有依赖关系的两个项目组同时开发时，可以互不影响，每次A项目组发布后，B项目组都会刷新、重新编译的方式，自动更新到最新的A项目开发的依赖包。只有当准备进入测试阶段，才会将里程碑版本号的SNAPSHOT替换成alpha或beta，即测试版本。

2.3 测试版本`alpha`、`beta`

当一个项目开发完成后，就会进入测试版本，而测试版本一般会分为内部测试 alpha版、外部测试 beta版两种。

alpha和beta区别就是beta版会向外公开，而alpha版不会。

alpha(α)：预览版，或者叫内部测试版；一般不向外部发布，会有很多Bug；一般只有测试人员使用。
beta(β)：测试版，或者叫公开测试版；这个阶段的版本会一直加入新的功能；在 Alpha版之后推出。

因为处于测试阶段，肯定会有来回变的情况，那里程碑版本号的排序是怎么排的，它是按照字符串进行比较大小的,就比如：1.3-alpha-2 >1.3-alpha-10。

下边有几个扩展，如下：
扩展一：

α、β、λ 常用来表示软件测试过程中的三个阶段。

-- α(alpha) 是第一阶段，一般只供内部测试使用；

-- β(beta)是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存
在缺陷和漏洞，一般只提供给特定的用户群来测试使用；

-- λ(lambda)是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的
优化处理即可上市发行。

扩展二：

二.软件开发版本分类描述

Alpha：软件或系统的内部测试版本，会有很多Bug，仅内部人员使用
Beta：软件或系统的测试版本，这一版本通常是在Alpha版本后，会有很多新功能，
同时也有不少Bug
Gamma：软件或系统接近于成熟的版本，只需要做一些小的改进就能发行
RC（Release Candidate）：候选版本，这一版本不会增加新功能，多要进行Debug
GA（General Available）：正式发布版本，这个版本就是正式的版本 

一个介绍的好文章地址： 软件的 Alpha、Beta、GM、RC、GA 等版本到底是啥意思 
               https://www.bilibili.com/read/cv9270313

2.4 `rc`、`final`、`stable`、`release`、`GA`稳定版

当测试通过后，将会进入正式版本，正式版本很多都不一样，但是大概就这几种。大部分的正式版是啥也不带，就一个单纯的版本号，比如1.0、1.7.1等。也有个别的是这些 rc、final、stable、release、GA等。
正式版本就是稳定版，它在当期内是不会再变化了，表示测试通过，可以对外发布的版本。
正式版本也有排序，它的排序与里程碑版本号排序不同，正式版本就是以数字进行排序，比如1.10.1 > 1.7.1 > 1.5。

这里就需要提醒大家，一般我们下依赖，尽量不要下非稳定版本，像那种版本，基本都是有问题的，如果有稳定版，尽量用稳定版。
在这里插入图片描述

2.5 看下开源`nacos`的版本迭代情况

在学习版本号这块的时候，专门搜了下大厂的版本迭代情况，所以我就搜到了nacos这个。nacos源码地址
在这里插入图片描述
有的时候git地址访问不到，但大家可以从它提交git的tag版本，能够找到点感觉的。

大概能缕出下边的顺序。（注意看数字的变化）

在这里插入图片描述

简单的描述一下，即开始的时候，处于开发时期，都是SNAPSHOT版本。
当开发完成，进入内部测试alpha版本阶段，在内部测试阶段，递增的就是里程碑版本号，递增的时候是基于字符串进行排序递增，但是一般也不会出来那么多。（看nacos）。
经过内部测试完成后，进入公网测试beta版本阶段，当然有的测试就只有一个环境，不会分为内网和公网，这里就是假设我们是梦想中的环境，哈哈哈。当然又是递增里程碑版本号，还是基于字符串进行排序。
等公网测试趋于稳定，将会推出待稳定版本RC，基本这个版本不会出来什么问题，也可能会出来，我看上边nacos里，就有,如下图：
在这里插入图片描述
等RC版本没有出现问题后，才会真正出现最终稳定版。将里程碑版本号去掉，形成正式版本。
等大佬们又有了新的想法，开始升级的话，就会再进入下一轮的snapshot。

3. 最后

版本号我是认为比较重要的一项，以上仅仅是我参考《maven实战》和一些个人总结的理解。希望别误导大家，如果错了，请及时纠正我，感谢。
下一篇，maven中强大的scope标签详解。