服务端相关 / Maven 版本管理

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 从最开始的版本是如何演变成现在的模样的。(这里由于存在太多版本,所以,我们只截取了其中一部分)

(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 来管理这些版本。