Question

Maven似乎能够指出一系列版本，例如<version>[1.2.3,)</version>当没有所有开源软件包遵循的一致版本控制方案时，maven如何确定什么是新版本或旧版本。例如

junit 4.10
slf4j 1.7.2
Hibernate 4.1.7.Final
春天3.1.2.RELEASE

maven如何确定maven中包的旧版和新版？如果包使用字母作为A，B，C或A2，A2，A4等行的版本号，那该怎么办。

是否应该有标准的官方方式在maven中对软件包进行版本化？像spring和hibernate这样的常见开源软件包是否忽略了这种版本控制惯例？

Answer 1

从3.0版开始，Maven使用一致的系统来比较各个版本和版本范围的版本号。一旦你理解了一些问题，这个系统现在很有意义。

所有比较现在由ComparableVersion完成，其中说：

混合“-”（破折号）和“.”（点）分隔符，

字符和数字之间的转换也构成了一个分隔符：1.0alpha1 =＆gt; [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}}，然后发布1.0-SNAPSHOT或1.0-beta1，让Maven明白这些是后来的。

另请注意，1.0-rc1与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，M2Eclipse等支持。

Answer 2

根据this reference，Maven要求该版本的格式为：

<MajorVersion [> . <MinorVersion [> . <IncrementalVersion ] ] [> - <BuildNumber | Qualifier ]>

MajorVersion ， MinorVersion ， IncrementalVersion 和 BuildNumber 都是数字和限定符是一个字符串。 如果您的版本号与此格式不符，则整个版本号将被视为限定符。

如果使用不遵循此版本控制方案的工件，那么引用将解释您可能“遇到问题”（特别是对于Maven版本范围）。查看文章中链接的Maven source code非常有帮助。

在您给出的示例中，Hibernate和Spring工件似乎偏离了使用“.”而不是“-”来分隔限定符。

我的一些实验表明，DefaultArtifactVersion将完全按照上述描述解析版本号。也就是说，给定（3.1.2.RELEASE）的Spring示例将被解释为：

专业：0
Minor：0
增量：0
限定符：3.1.2.RELEASE

更重要的是，两个版本号的比较（如果使用Maven 3.0或更新版本）很多更灵活。版本号被分成项目列表（.或-标记项目之间的边界，请注意.的优先级高于-。然后通过在术语中获取每个项目并执行自然顺序比较来完成比较。因此，3.1.2.RELEASE将被视为小于3.1.3.RELEASE。字符串也被比较，因此3.1.2.RELEASD将被视为小于3.1.2.RELEASE。有一些特殊的字符串具有特殊的等价物，例如3.1.3.a.1将与3.1.3.alpha.1

排序相同

但是，虽然比较在较新版本的Maven中更灵活。版本范围边界仍然使用Major：Minor：Incremental：Qualifier方案进行评估，因此如果您使用版本范围，则灵活性不太有用。

Answer 3

这是一个直接针对Maven的ComparableVersion类编写的测试。

package org.codehaus.mojo.buildhelper.versioning;

import org.apache.maven.artifact.versioning.ComparableVersion;
import org.junit.Assert;
import org.junit.Test;

public class TempTest {
    @Test
    public void testVersions() {
        Assert.assertTrue(new ComparableVersion("1.0-beta1-SNAPSHOT").compareTo(
                new ComparableVersion("1.0-beta1")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-beta1").compareTo(
                new ComparableVersion("1.0-beta2-SNAPSHOT")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-beta2-SNAPSHOT").compareTo(
                new ComparableVersion("1.0-rc1-SNAPSHOT")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-rc1-SNAPSHOT").compareTo(
                new ComparableVersion("1.0-rc1")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-rc1").compareTo(
                new ComparableVersion("1.0-SNAPSHOT")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-SNAPSHOT").compareTo(
                new ComparableVersion("1.0")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0").compareTo(
                new ComparableVersion("1")) == 0);
        Assert.assertTrue(new ComparableVersion("1.0").compareTo(
                new ComparableVersion("1.0-sp")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-sp").compareTo(
                new ComparableVersion("1.0-whatever")) < 0);
        Assert.assertTrue(new ComparableVersion("1.0-whatever").compareTo(
                new ComparableVersion("1.0.1")) < 0);
    }
}

此测试断言Maven认为以下版本从最低到最高：

1.0-β1-SNAPSHOT
1.0-β1
1.0-β2-SNAPSHOT
1.0-RC1-SNAPSHOT
1.0-RC1
1.0-SNAPSHOT
1.0和1（这些是相同的）
1.0-SP
1.0的任何
1.0.1

Answer 4

您对使用major / minor / incremtal /等的假设是完全错误的。比较在ComparableVersion中完成，其中包含实现。 ctor将致电使用parseVersion(...)的{{1}}，该ComparableVersion存储为DefaultArtifactVersion中的实例，并在compareTo(..)期间使用

有getMajor..等部分，但这些部分无法正常工作。这就是be marked deprecated的原因。

Stehpen Collony的信息适用于Maven 2，但不再适用于Maven 3。

maven如何排序版本号？

4 个答案: