本文同意轉載，但請標明出處:http://blog.csdn.net/wanghantong/article/38424065, 版權全部
如今所說的maven版本號不同於SVN的版本號控制哦！！！
之前我們說過Maven的版本號分為快照和穩定版本號，快照版本號使用在開發的過程中，方便於團隊內部交流學習。而所說的穩定版本號，理想狀態下是項目到了某個比較穩定的狀態。這個穩定包括了源碼和構建都要穩定。
一、怎樣衡量項目的穩定狀態呢？
1. 所有的自己主動化測試應當所有通過
2. 項目沒有配置不論什么快照版本號的依賴
3. 項目沒有配置不論什么快照版本號的插件
4. 項目所包括的代碼都已經所有提交到了版本號控制系統中
5.我們應當再一次運行Maven構建，以確保項目的狀態是OK的
6. 我們將這一次變更提交到版本號控制的主干中，並打上標簽
僅僅有滿足了上述6個條件, 我們就能夠將這一個快照版本號更新至公布版本號
二、在開發的過程中，版本要怎樣進行變更呢？Maven是否有潛在的約定？
我們在開發的過程中。下載jar包的時候常常會發現某個jar類似這樣：1.2.3-beat-4.jar
多么復雜的一個名稱。。
。
以下來解釋一下。這里每一個數字的含義：
“ 1 ” : 表示該版本號的第一個重大版本號
“ 2 ” : 表示這是基於重大版本號的第二個次要版本號
“ 3 ” : 表示該次要版本號的第三個增量
" beat-4" : 表示該增量的一個里程碑
用一個圖來描寫敘述：
< 主版本號 > ------ < 次版本號 > ------ < 增量版本號 > ------ < 里程碑版本號 >
主版本號：表示了項目的重大架構變更 struts1 -- struts2
次版本號：表示較大范圍的功能添加和變化 Nexus1.5 ---- Nexus1.4
增量版本號：一般表示重大Bug修復
里程碑版本號：指某一個版本號的里程碑 *.*-alpha-1 *.*-beat-1
看起來有點麻煩啊。 可是在一般來說，我們僅僅會聲明主版本號和次版本號，增量版本號和里程碑版本號就不一定了。
注：maven中約定的版本號次序：
對於主版本號、次版本號、增量版本號來說他們的比較是基於數字的。因此：1.5>1.4>1.3>1.2.11>1.2.8
對於里程碑版本號來說，比較是基於字符串的。因此：1.5>1.4>1.3>1.2.3>1.2.11
三、主干、分支、標簽
上面的筆記中提到了主干和標簽，究竟怎樣理解主干、分支、標簽呢？
主干: 項目開發代碼的主體，是從項目開始到當前都處於活動的狀態，從這里能夠獲得項目最新的源碼和差點兒全部的變更歷史
分支: 從主干的某個點分離出來的代碼拷貝。通常能夠在不影響主干的前提下。在這里進行重大的bug修復或者實驗性質的開發。假設達到了預期的目的，通常將這里的變更合並到主干中去。
標簽: 用來標識主干或者分支的某個點的狀態，以代表項目的某個穩定狀態，也就是通常說的公布狀態
這三個元素，能夠清晰的描寫敘述出項目的版本號管理，並且也已經成了一個默認的行業標准。
四、自己主動化版本號公布
用久了手動版本號公布之后。我們會想到是否能進行自己主動化的公布版本號。答案是肯定的，這將引入一個新的插件：Maven Release Plugin
通過一些必要的配置。就能夠完畢版本號公布
Maven Release Plugin 插件簡單介紹：
該插件主要有三個目標：release: prepare, release: rollback, release: perform (什么是插件目標)，在介紹分支自己主動化的時候還會引入branch目標
①release:prepare 准備版本號公布。依次運行下列操作
1. 檢查項目是否有未提交的代碼
2. 檢查項目是否有快照版本號依賴
3. 依據用戶的輸入將快照版本號升級為公布版
4. 將POM中的SCM信息更新為標簽地址
5. 基於改動后的POM運行maven構建
6. 提交POM變更
7. 基於用戶輸入為代碼打標簽
8. 將代碼從公布版升級為新的快照版
9.提交POM變更
release: rollback
回退release: prepare所運行的操作。
將POM回退至release:prepare之前的狀態。並提交。
注：該步驟不會刪除release:prepare生成的標簽，須要用戶手動刪除
release: perform
運行版本號公布
簽出release:prepare生成的標簽中的源碼，並在此基礎上運行mvn deploy命令打包並部署構件至倉庫
注：要為項目公布版本號，首先須要為其加入正確的版本號控制系統信息(這是由於Maven Release Plugin須要知道版本號控制系統的主干、標簽等地址后才干運行相關操作)
②分支的自己主動化創建
先看一下Maven Release Plugin 的branch目標能幫助我們做哪些事情
1. 檢查本地有無未提交的代碼
2. 將分支更改POM的版本號。如：1.1.0-SNAPSHOT改成1.1.1-SNAPSHOT
3. 將POM中的SCM信息更新為分支地址
4. 提交以上更改
5. 將主干代碼拷貝到分支中
6. 改動本地代碼使其回退到分支前的版本號(用戶能夠指定新的版本號)
7. 提交本地更改
注：此時也必須正確的配置SCM信息
五、代碼安全
代碼安全是我們比較關心的一個問題， 比方說。當我們從中央倉庫下載第三方構件的時候，我們可能要去驗證這些文件的合法性，或者當我們公布項目后。使用我們項目的人也要驗證
引入一個新的插件：Maven GPG Plugin 自己主動的完畢簽名
在使用Maven GPG Plugin之前，首先須要確定GPG是可用的，然后再POM中配置插件就可以
pom.xml
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-gpg-plugin</artifactId> <version>1.0</version> <executions> <execution> <id>sign-artifacts</id> <phase>verify</phase> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin>
然后使用一般的Maven命令簽名並公布項目構件
$mvn clean deploy -Dgpg.passphrase=****
注：
1. 假設不提供 -Dgpg.passphrase參數，執行時就會要求輸入password
愛自己的最好方式就是努力奮斗讓自己優秀起來。假設你再頹廢，別郁悶沒有知己、找不到真愛，由於連你自己都不愛自己，還妄想別人愛你嗎?
試問，你有什么值得愛，你配嗎?
往往一個人在乎的不是金錢而是一顆奮斗的心啊!醒悟吧!別再墮落了!