如今所說的maven版本號不同於SVN的版本號控制哦！！！
之前我們說過Maven的版本號分爲快照和穩定版本號，快照版本號使用在開發的過程中，方便於團隊內部交流學習。而所說的穩定版本號，理想狀態下是項目到了某個比較穩定的狀態。這個穩定包括了源碼和構建都要穩定。
一、怎樣衡量項目的穩定狀態呢？
所有的自己主動化測試應當所有通過
項目沒有配置不論什麼快照版本號的依賴
項目沒有配置不論什麼快照版本號的插件
項目所包括的代碼都已經所有提交到了版本號控制系統中
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 準備版本號公佈。依次運行下列操作
檢查項目是否有未提交的代碼
檢查項目是否有快照版本號依賴
依據用戶的輸入將快照版本號升級爲公佈版
將POM中的SCM信息更新爲標籤地址
基於改動後的POM運行maven構建
提交POM變更
基於用戶輸入爲代碼打標籤
將代碼從公佈版升級爲新的快照版
9.提交POM變更
release: rollback
回退release: prepare所運行的操作。
將POM回退至release:prepare之前的狀態。並提交。
注：該步驟不會刪除release:prepare生成的標籤，須要用戶手動刪除
release: perform
運行版本號公佈
簽出release:prepare生成的標籤中的源碼，並在此基礎上運行mvn deploy命令打包並部署構件至倉庫
注：要爲項目公佈版本號，首先須要爲其加入正確的版本號控制系統信息(這是由於Maven Release Plugin須要知道版本號控制系統的主幹、標籤等地址後才幹運行相關操作)
②分支的自己主動化創建
先看一下Maven Release Plugin 的branch目標能幫助我們做哪些事情
檢查本地有無未提交的代碼
將分支更改POM的版本號。如：1.1.0-SNAPSHOT改成1.1.1-SNAPSHOT
將POM中的SCM信息更新爲分支地址
提交以上更改
將主幹代碼拷貝到分支中
改動本地代碼使其回退到分支前的版本號(用戶能夠指定新的版本號)
提交本地更改
注：此時也必須正確的配置SCM信息
五、代碼安全
代碼安全是我們比較關心的一個問題， 比方說。當我們從中央倉庫下載第三方構件的時候，我們可能要去驗證這些文件的合法性，或者當我們公佈項目後。使用我們項目的人也要驗證
引入一個新的插件：Maven GPG Plugin 自己主動的完畢簽名
在使用Maven GPG Plugin之前，首先須要確定GPG是可用的，然後再POM中配置插件就可以
pom.xml
org.apache.maven.plugins
maven-gpg-plugin
1.0
sign-artifacts
verify
sign
然後使用一般的Maven命令簽名並公佈項目構件
$mvn clean deploy -Dgpg.passphrase=**
注：
1. 假設不提供 -Dgpg.passphrase參數，執行時就會要求輸入password
本文同意轉載，但請標明出處:http://blog.csdn.net/wanghantong/article/38424065,
版權全部