Maven似乎有能力指出一系列的版本,如<version>[1.2.3,)</version>
,当没有所有开源软件包都遵循的一致的版本控制方案时,maven如何确定什么是新版本或旧版本。例如
- junit
4.10
- slf4j
1.7.2
- Hibernate
4.1.7.Final
- Spring
3.1.2.RELEASE
maven是如何计算什么是老年人vs. maven中的软件包的新版本?如果软件包使用字母作为版本号,沿着A,B,C或A2,A2,A4的线条沿着。等
在maven中是否应该有一个标准的官方方法来版本化软件包?像spring和hibernate这样的常见开源软件包是否忽略了这种版本控制约定?
3条答案
按热度按时间pdsfdshx1#
从3.0版开始,Maven使用一致的系统来比较各个版本和版本范围的版本号。一旦你理解了一些陷阱,这个系统现在就很有意义了。
所有的比较现在都是由ComparableVersion完成的,它说:
-
”(破折号)和“.
”(圆点)分隔符,1.0alpha1
=>[1, 0, alpha, 1]
alpha
或a
beta
或b
milestone
或m
rc
或cr
snapshot
ga
或final
sp
这意味着版本按照以下顺序出现,我认为这是完全有意义的,除了中间的1.0-SNAPSHOT:
1.0-beta1-SNAPSHOT
1.0-beta1
1.0-beta2-SNAPSHOT
1.0-rc1-SNAPSHOT
1.0-rc1
1.0-SNAPSHOT
1.0
1.0-sp
1.0-whatever
1.0.1
我在所有这些中发现的主要问题是,
snapshot
在 *beta
或rc
之后,所以你不能有1.0-SNAPSHOT
的开发版本,然后发布1.0-beta1
或1.0-rc1
,让Maven理解这些是以后的版本。另外请注意,
1.0-beta-1
与1.0beta1
完全相同,1.0
与1
或1.0.0
完全相同。版本范围现在也以您期望的方式工作(几乎)。例如,
[1.0-alpha-SNAPSHOT,1.0]
将查找1.0-beta1-SNAPSHOT
、1.0-beta1
、1.0-rc1-SNAPSHOT
、1.0-rc1
、1.0-SNAPSHOT
或1.0
,优先选择后面的项而不是前面的项。mvn versions:resolve
、M2 Eclipse等完全支持这一点。nkkqxpd92#
这是一个直接针对来自Maven的ComparableVersion类编写的测试。
此测试Assert以下版本被Maven认为是从最低到最高的:
h6my8fg23#
你关于使用major/minor/incremtal/etc的假设。是完全错误的比较是在包含实现的ComparableVersion中完成的。ctor将调用
parseVersion(...)
,它使用ComparableVersion
,ComparableVersion
作为示例存储在DefaultArtifactVersion
中,并在compareTo(..)
期间使用有
getMajor..
等部件。但它们不能正常工作这就是为什么会be marked deprecated。Stehpen Collony的信息对于Maven 2是正确的,但不再适用于Maven 3。