Maven 版本管理

本节中，我们来介绍一下 Maven 是如何进行版本管理的。如何在项目的实际开发中，结合 Maven 来推进项目的进行。一个正常的项目的开发周期通常是很长的，这个过程当中，需要发布很多个版本，那这些版本如何表示，而我们又应该如何来管理这些版本呢？

1. 什么是版本管理

那什么是版本管理呢？首先，版本管理是不同于版本控制的。版本控制通常的概念是在软件开发过程中，管理程序文件，配置文件等文件的变化。更倾向于来追踪一个项目过程中，不同时期项目的变化。但是，版本管理则不同，通常是指一个项目过程中，不同时期版本的演化过程。通俗一点讲，版本管理就像人的成长过程中，从婴儿到少年到青年到中年一直到老年这个演变过程的管理；版本控制则更关注细节，例如这个时期，身高从 160cm 长到了 165cm，或者体重 60kg 变为了 62kg 等等。

2. 约定版本号

我们理解了什么是版本管理，那 Maven 是如何做的呢？

通常情况下，Maven 的版本号约定中包括如下几个部分：

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

• 主版本号：主版本号表示该项目的重大升级。例如：Maven1 到 Maven2；
• 次版本号：表示在该主版本下，较大范围的升级或变化。例如：Maven-3.0 到 Maven-3.1；
• 增量版本号：增量版本通常是用来修复bug的版本。例如：Maven-3.1.1；
• 里程碑版本号：用来标记里程碑版本。例如：Maven-3.0-alpha-3。

由于 Maven 已经维护了将近 20 年，所以，使用 Maven 这个项目的版本演变过程来举例是再合适不过了。我们打开 Maven 的官网，找到 Release Notes，打开便可以看到 Maven 从最开始的版本是如何演变成现在的模样的。（这里由于存在太多版本，所以，我们只截取了其中一部分）

注意： 有的同学可能会问，里程碑版本里面的 alpha，beat 是什么意思？

• alpha 版本： alpha 版本被称为是内测版本。通常会存在比较多 bug，主要是面向测试人员使用；
• beat 版本： 这个版本也是测试版本。会比 alpha 版本新增加一些功能；
• RC 版本： 即将发布的候选版本。这个阶段不会再新增功能，主要用于修复 Bug；
• GA 版本： 正式发布版本，也可以对应于 release 版本。

这些版本号在一些流行的框架的演变过程中非常常见。

3. 主干、分支与标签

通常情况下，我们在进行项目开发的过程中，会使用到版本控制工具，例如 svn 或者 git，这时候就会涉及到主干，分支以及标签的概念，那么这里我们简单介绍一下这三个概念。

3.1 概念

• 主干： 通常是项目代码的主体。会存在于整个项目周期中，其他的所有分支都是从这里开始的，一般情况下，项目最新的源代码或者所有的变更记录都可以在这里找到；
• 分支： 从主干中某个节点分离出来的代码。在分支刚刚创建的时候，具有当时主干中所有的源代码。通常分支是为了修改某些 Bug 或者进行一些其他的开发，这些源代码的修改并不会影响主干。一旦这个分支中的代码验证通过后，可以将代码归并到主干中去；
• 标签： 通常用来标记主干或者分支中某个时间节点的状态，

从下面的图中，我们可以比较清晰地看出，主干，分支与标签三者之间的关系：

3.2 创建分支

我们在了解了主干以及分支的概念之后，那么我们如何去创建分支呢？通常情况下我们可以使用 Svn 或者 Git 自带的创建分支的方式来创建需要的分支，但是，这个时候会存在一个问题：我们需要手动去修改新创建出的分支的 pom.xml 文件中的内容。既然说到版本管理，那想必 Maven 肯定是可以帮助我们做这件事情的。

那么接下来我们来看一下如何使用 Maven 来创建分支，这里我们使用 Git 配合 Maven 来演示如何创建分支。

我们想要使用 Maven 来帮助我们创建分支，首先我们需要配置 scm ，这样 Maven 就可以来代替 Git 来进行操作。

这里我们在 gitee 上创建一个仓库来放置我们的项目。

1. 将 scm 配置到 pom.xml 文件中：

<scm>
	<connection>scm:git:git@gitee.com:jhulk/first-project.git</connection>
	<developerConnection>scm:git:git@gitee.com:jhulk/first-project.git</developerConnection>
</scm>

2. 将 maven-release-plugin 插件配置到 pom.xml 文件中：

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-release-plugin</artifactId>
        <version>2.5.3</version>
        <configuration>
            <tagNameFormat>${project.version}</tagNameFormat>
            <autoVersionSubmodules>true</autoVersionSubmodules>
        </configuration>
    </plugin>
</plugins>

3. 执行 mvn release:branch -DbranchName=1.0.1 -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false 命令：

• -DbranchName： 目标分支。这里我们可以根据需要来自定义新分支的命名结构；
• -DupdateBranchVersions： 在分支中更新版本；
• -DupdateWorkingCopyVersions： 在当前分支更新版本。

在执行的时候， Maven 会问 branch version 是否为 1.0.1-SNAPSHOT？这个是我们想要的，直接 enter 即可。

执行完成之后，我们查看 Git 的远程仓库中，可以看到新生成的分支。

4. 执行 mvn release:prepare 命令：

在执行的时候，Maven 会问 release version 是否是 1.0.0？这个是否是我们想要的，直接选择 enter 即可。

紧接着，Maven 会问我们 release tag 是否是1.0.0-SNAPSHOT？这个也是我们想要的，直接 ente r即可。

紧接着，Maven 会问我们新的版本是否是1.0.1-SNAPSHOT？这里输入新版本为1.1.0-SNAPSHOT，然后 enter。

执行成功之后，我们更新一下代码，会发现，主干上的 pom.xml 文件的版本已经升级为1.1.0-SNAPSHOT了。

4. 小结

本节当中，我们着重介绍了在 Maven 的世界中，我们一般是如何来约束版本的，以及这些约束所代表的含义，最后，我们还介绍了如何使用 Maven 来管理这些版本。