[原创]maven release使用说明
maven release插件的介绍
maven release是用于提供在将maven工程，从开发转为发布的时候自动修改包版本使用的；在工程依赖负责的时候，避免了手工修改可能导致的问题；具体举个例子：
这个是一个很现实的工程，工程中 ecp-services 是所有的服务包，服务包之间根据业务的需求会有部分的耦合；原来开发的时候所有的版本都是使用了 snapshot；而到了正式发布的时候，需要修改为release；那么这么多个包，就需要挨个修改；而且其中依赖的版本也需要从 snapshot 修改为release ;很容易出现错漏； 针对这样的问题，引入 maven release插件可以很智能得解决这个问题；
使用介绍
在工程的顶级父pom.xml中增加以下配置
其中引用了 release插件，目前建议使用2.5.3 的版本；
几个实例的测试
例子中的源码是使用了git
release:update-version
修改当前工作区的pom的版本号，包括子模块，及模块之间相互依赖的版本号； mvn --batch-mode release:update-versions -DdevelopmentVersion=1.3.3-SNAPSHOT -DupdateDependencies=true
updateDependencies的参数在2.5.2之后的版本支持，所以release-plugin的版本要求为2.5.2 ，以上命令执行之后，会修改当前工作分支的pom的版本号为1.3.3-SNAPSHOT，包括将子模块和子模块互相依赖的版本进行调整；update-release的描述
release:branch
打分支，并修改分支的版本号；官方release:branch的参数说明
mvn release:branch -DbranchName=1.1.1 -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DdryRun=true -DpushChanges=false
- 这个打分支的脚本，版本不会修改为 release，还是原来的snapshot
- -DdevelopmentVersion=1.0.3 -DupdateWorkingCopyVersions=true 执行当前工作区新的版本号，如果当前工作区版本号不需要修改，则 DupdateWorkingCopyVersions 设置为false;
- -DdryRun=true 用于在进行验证的时候使用，该参数设置为true，则不会提交到版本控制区，只会在当前版本修改版本号；会生成一个pom.xml.branch的文件；这个是分支的文件；
- -DpushChanges=false 用于git，表示是否往远端推送当前的变更；默认true 会推送；
- -DreleaseVersion=1.0.1-SNAPSHOT -DupdateBranchVersions=true 用于指定新的分支的版本号；新分支的版本号如果要修改，则：updateBranchVersions 必须设置为true;
- -DupdateVersionsToSnapshot=true 是否将分支版本修改为 Snapshot
mvn release:branch -DbranchName=1.2.1 -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DdryRun=true -DpushChanges=false
本地不会有分支，多出了pom.xml.branch的文件，在该文件中修改了版本号；
mvn release:branch -DbranchName=1.2.1 -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DpushChanges=false
本地有分支，创建分支之后，又退回到当前branch ； git的路线如下图所示
mvn release:branch -DbranchName=1.3.1 -DreleaseVersion=1.3.1-RELEASE -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DupdateVersionsToSnapshot=false -DdryRun=true -DpushChanges=false
这样写是没用的，一样不会变成 release 版本；出来的版本号，由于原来是1.0.0-SNAPSHOT；新的分支的版本号变成是：1.3.1-RELEASE-SNAPSHOT；
release:prepare
先给一个prepare的官网说明；以下是一些常用的参数特别说明和例子；
- mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.0.1-RELEASE -Dtag=busi-1.0.1-RELEASE -DignoreSnapshots=true
-DupdateWorkingCopyVersions=false 设置为false 表示不修改当前工作区的版本号；如果设置为 true，则需要增加一个参数：-DdevelopmentVersion=1.0-SNAPSHOT表示当前工作区新的版本号； -DreleaseVersion=1.0.1-RELEASE 表示打的tag的版本号； -Dtag=busi-1.0.1-RELEASE -DtagNameFormat=@{project.artifactId}-@{project.version} 表示tag的名字，默认的tagNameFormat就是@{project.artifactId}-@{project.version}，所以没有配置 tag ，也会有tag出来，而且tag的名字就是根据tagNameFormat出来的格式；
- mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.0.1-RELEASE -Dtag=busi-1.0.1-RELEASE -DignoreSnapshots=true -DdryRun=true
带上了 -DdryRun的参数，设置为true，在执行之后并不会真的打tag了，而是生成一个对应的pom.xml.tag文件，这个文件是指tag中使用的pom.xml;
- mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.1.1-RELEASE -Dtag=busi-1.1.1-RELEASE -DignoreSnapshots=true -DpushChanges=false
以上命令执行完成之后，会在本地生成一个tag，tag名称为：ecp-busi-1.1.1-RELEASE；其中对应得版本路径如下所示；
特别说明
- 执行了 release:prepare之后，tag打了，在目录下还会遗留下 pom.xml.releaseBackup 、release.properties的文件，这个是用于如果执行的时候，出现了错误，进行回退使用的；回退命令：release:rollback；回退之后会将之前打的tag删除了；
- 如果执行正确，可以使用release:clean 命令清理 pom.xml.releaseBuckup 和 relase.properties文件；
- 执行了release:prepare之后，可以通过 release:perform进行打包生成；--当然也可以不做这一步；注意：执行了release:prefomr会自动执行release:clean
结合 maven release插件进行的代码发布版本控制
流程1
目前我们为了保证开发的流畅性，每次的要发布的代码是基于某个开发主干进行打发布分支的；而发布分支的包版本就已经调整为 release 了，所以我们使用的流程如下：
- 基于开发主干/或者某个开发分支，执行 release:prepare的操作，打出一个发布的tag (release-tag);
mvn release:clean release:prepare -DupdateWorkingCopyVersions=false -DreleaseVersion=1.1.1-RELEASE -Dtag=busi-1.1.1-RELEASE -DignoreSnapshots=true - 基于发布的tag ，生成一个branch (release-branch)
- svn 使用 cp 命令
- git 使用 git checkout tagname -b branch_tagname 其中的tagname 是指tag的名称
流程2
为了保证延续性，让开发分支每次打了release之后，开发版本递增；发布分支刚开始的时候也使用snapshot版本，在正式发布的时候使用release，就可以采用以下的流程：
- 基于开发/或者某个开发分支，执行 release:branch 命令，打出一个 release 分支；（包版本是 snapshot）；
mvn release:branch -DbranchName=branch-1.2.1-release -DreleaseVersion=1.2.1-SNAPSHOT -DupdateBranchVersions=true -DdevelopmentVersion=1.2.2-SNAPSHOT -DupdateWorkingCopyVersions=true -DupdateVersionsToSnapshot=false
以上将会出现一个branch-1.2.1-release的分支，并且版本为：1.2.1-SNAPSHOT，并且开发分支的版本修改为：1.2.2-SNAPSHOT；如果不希望修改开发分支的版本，则：-DupdateBranchVersions=false 并去掉 -DdevelopmentVersion=1.2.2-SNAPSHOT
- QA 在发布分支测试通过之后，对发布分支打上tag ; mvn release:prepare的操作，执行成功之后，执行mvn release:preform 进行打包处理（或者 checkout tag的代码，通过 maven 命令进行打包 deploy / package 之类的）；
目前我们使用的是第一种方式；因为我们为了保证包的正确性，在QA打了tag之后，还需要不断的测试；如果出现问题，要删除tag，并通过2的命令重新进行release:prepare的处理；所以，我们干脆就开始就给release，之后QA每次清理本地maven仓库的包，重新打release包；
本文档是 maven release + git 验证通过；实际上 maven release + svn 也是可以的（我们在迁移到git之前一直用的是svn），流程一样
