Maven 学习总结 （六） 之 版本
版本管理
版本管理是指项目整体版本的演变过程管理。版本控制是指借助版本控制工具（如Subversion）追踪代码的每一个变更。
为了方便团队合作，项目开发过程中，大家应该使用快照版本，快照版本机制促进团队内部的交流，但是当项目需要对外发布时，我们显然需要提供非常稳定的版本，
使用该版本应当永远只能定位到唯一的构件，而不是像快照版本那样，定位的构件随时可能发生变化。我们称这类稳定的版本为发布版。项目发布了一个版本之后，就
进入下一个开发阶段，项目也就自然转到新的快照版本中。
版本管理关心的问题之一就是这种快照版和发布版之间的转换。项目经过了一段时间的 x.0-SNAPSHOT开发之后，在某个时刻发布了x.0正式版，
然后项目进入了x.1-SNAPSHOT的开发。
理想的发布版本应当对应了项目某个时刻比较稳定的状态，这包括源代码的状态以及构建状态，因此这个时候项目的构建应当满足以下的条件：
- 自动化测试应当全部通过
- 项目没有配置任何快照版本的依赖
- 项目没有配置任何快照版本的插件
- 项目所包含的代码已经全部提交到版本控制体系中
版本控制系统记录了代码的每个变化，通常这些变化都被维护在主干（Trunk）中，当项目发布的时候，开发人员应该使用标签记录这一特殊时刻的状态，
这样可以明确将某个源码版本从主干中标记出来，放到单独的位置，这样在之后的任何时刻，我们都能够快速地得到版本的源代码，从而能够比较各个版本
的差异，甚至重新构建一个同样版本的构建。
Maven的版本号定义约定是这样的：
<主版本>.<次版本>.<增量版本>-<里程碑版本>
- 主版本，表示了项目的重大架构变更。
- 次版本， 表示较大范围的功能增加和变化，及Bug修复。
- 增量版本， 一般表示重大Bug的修复。
- 里程碑版本， 这往往指某一个版本的里程碑。例如，Maven3已经发布了很多里程碑版本，如 3.0-alpha-1等。这样的版本与正式的3.0相比，往往表示不是非常稳定，
还要更多测试。
主干、标签与分支，使用版本控制工具时我们都会遇到主干（trunk）、标签（tag）和branch（分支）的概念。
- 主干，项目开发代码的主体，是从项目开始直到当前都处于活动的状态。从这里可以获得项目最新的源代码以及几乎所有的变更历史。
- 分支， 从主干的某个点分离出来的代码拷贝，通常可以在不影响主干的前提下在这里进行重大Bug的修复，或者做一些实验性质的开发。如果分支达到了预期的目的
通常发生在这里的变更会被合并（merge）到主干中。
- 标签， 用来标识主干或者分支的某个点的状态，以代表项目的某个稳定状态，通常是版本的发布时状态。
使用maven管理项目版本的时候，涉及了很多版本控制系统操作，下面的例子介绍这些操作如何执行。该图展示的是一个典型的项目版本变化过程。
自动化版本发布，当熟悉了版本发布流程之后，就会希望借助工具将这一流程自动化，Maven Release Plugin提供了这样的功能，只要提供一些必要的信息，它就能
帮我们完成上述所有版本发布所涉及的操作。
Maven Release Plugin主要由三个目标，他们分别为：
- release：prepare 准备版本发布，依次执行下列操作
检查项目是否有未提交的代码
检查项目是否有快照版本依赖
根据用户的输入将快照版本升级为发布版本
将POM中的SCM信息更新为标签地址
基于修改后的POM执行Maven构建
提交POM变更
基于用户输入为代码打标签
将代码从发布版升级为新的快照版
提交POM变更
- release ： rollback 回退release ： prepare所执行的操作。将POM回退至release: prepare之前的状态，并提交。需要注意的是，该步骤不会删除release:prepare生成的标签，
因此用户需要手动删除。
- release: perform 执行版本发布。签出release: prepare生成的标签中的源代码，并在此基础上执行mvn deploy命令打包并部署构件至仓库。
要为项目发布版本，首先需要为其添加正确的版本控制系统信息，这是因为maven release plugin需要知道版本控制系统的主干、标签等地址信息后才能执行相关的操作。
一般项目配置信息代码如下图：
connection表示一个只读的scm地址，developerConnection元素表示可写的scm地址，url则表示可以在浏览器中访问的scm地址。为了能让Maven识别，connection和developerConnection
必须以scm开头，冒号之后的部分表示版本控制工具的类型。该配置只告诉Maven当前代码的位置（主干），而版本发布还要涉及标签操作。还需要配置Maven Release Plugin告诉其标签基础
目录，如图：
一切就绪之后运行命令：$mvn release:prepare , Maven Release Plugin开始准备发布版本，如果检测到项目有未提交代码，或者有快照版本的依赖，则会提示出错。如果没有问题，则会提示
用户输入想要发布的版本号、标签的名称以及新的快照版本号。
如果项目的artifactId为app，发布前版本为1.0.0-SNAPSHOT，则Maven Release Plugin会提示使用发布版本号1.0.0，使用标签名app-1.0.0,新的开发版本为1.0.0-SNAPSHOT。如果这些
值是你想要的直接按ENTER，否则填入想要值按ENTER。
基于这些信息，Maven Release Plugin会将版本从1.0.0-SNAPSHOT更新为1.0.0，并更新SCM地址http://192.168.1.103/app/trunk至http://192.168.1.103/app/tags/tag/app-1.0.0.并运行一
次Maven防止意外的错误出现，然后提交变化。为该版本打上标签。标签地址是http://192.168.1.103/app/tags/app-1.0.0。即tagBase路径加上标签名称。之后，Maven Release Plugin将POM
中的版本信息1.0.0升级到1.1.0-SNAPSHOT并提交。
到此，release:prepare工作完成。如果这是发现一些问题，可以使用release:rollback命令回退发布，Maven Release Plugin会将POM的配置回退到release:prepare之前的状态。
多个模块项目中执行release:prepare的时候，默认maven-release-plugin会提示用户设定每个模块发布版本号及新的开发版本号。
如果检查release:prepare结果没有问题，标签和新的发布版本都是正确的，可以执行$mvn release:perfom, 该命令将标签中的代码签出执行mvn deploy命令构建版本，并部署到仓库中。
自动化构建分支，在正式发布版本1.0.0的同时，还可以穿件一个分支来修复将来这个版本可能遇到的中大的Bug。这个过程可以手动完成，如使用svn copy操作将主干代码复制到一个名为
1.1.x的分支中，然后修改分支中的POM文件，升级其版本为1.1.1-SNAPSHOT，这会设计很多操作。
使用Maven Release Plugin的branch目标，它能帮我们自动化这些过程：
- 检查本地有无未提交的代码
- 为分支更改POM的版本，例如从11.0-SNAPSHOT改成1.1.1-SNAPSHOT
- 将POM中的SCM信息改为分支地址
- 提交以上更改
- 将主干的代码复制到分支中
- 修改本地代码使其回退到分支之前的版本
- 提交本地更改
为了让Maven Release Plugin正常工作，和版本发布一样，必须在POM中提供正确的SCM信息。此外由于分支操作会涉及版本控制系统里的分支地址，因此还要为其配置分支基础目录。
然而tagBase和branchBase并非是一定要配置的。如果为版本控制仓库使用了标准的布局，即在平行的trunk/tags/branches目录下分别放置项目主干代码、标签代码和
分支代码。那么Maven Release Plugin就能够自动根据主干代码位置计算出标签及分支代码的位置，因此你就可以省略这两项配置。
