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标签详解。