10 Maven 版本管理

Maven 版本管理

一個健康的項目一般有一個長期、合理的版本演變過程。例如 Maven 自己的版本也比較多，如最先的 Maven1；Maven2 有 2.0.九、2.0.十、2.1.0、2.2.0、2.2.1 等各類版本；而最新的 Maven3 則擁有 3.0- alpha-一、3.0- alpha-二、3.0- alpha-七、3.0-beta-l 等版本。除了這些對外發布的版本以外， Maven 特有的快照版本的概念。這些版本中的每一個數字表明瞭什麼？ alpha、beta 是什麼意思？快照版和發佈版的區別是什麼？咱們應該如何科學地管理本身的項目版本？本章將會詳細解答這些問題。

閱讀本章的時候還須要分清版本管理(Version Management)和版本控制(Version Control)的區別。版本管理是指項目總體版本的演變過程管理，如從 1.0- SNAPSHOT 到 1.0，再到 1.1- SNAPSHOT。版本控制是指藉助版本控制工具(如 Subversion)追蹤代碼的每個變動。本章重點講述的是版本管理。

版本管理關心的問題之一就是這種快照版和發佈版之間的轉換。項目通過了一段時間的 1.0-SNAPSHOT 的開發以後，在某個時刻發佈了 1.0 正式版，而後項目又進入了 1.1-SNAPSHOT 的開發，這個版本可能添加了一些有趣的特性，而後在某個時刻發佈 1.1 正式版。項目接着進入 1.2-SNAPSHOT 的的開發。因爲快照對應了項目的開發過程，所以每每對應了很長的時間，而正式版本對應了項目的發佈，所以僅僅表明某個時刻項目的狀態。

1. Maven 版本號

Maven 的的版本號定義約定是這樣的：

<主版本>.<次版本>.<增量版本>-<里程碑版本>

看一個實際的例子，這裏有一個版本：1.3.4-beta-2。「1」 表示了該版本是第一個重大版本；「3」 表示這是基於重大版本的第三個次要版本；「4」 表示該次要版本的第四個增量；最後的「beta-2」 表示該增增量的某一個里程碑。

主版本和次版本之間，以及次版本和増量版本之間用點號分隔，里程碑版本以前用連字號分隔。下面解釋其中每個部分的意義：

1. 主版本：表示了項目的重大架構變動。例如， Maven2和 Maven1相去甚遠; Struts1和 Struts2採用了不一樣的架構; Junit4較 Junit3增長了標註支持。
2. 次版本：表示較大範圍的功能增長和變化，及Bug修復。例如 Nexus1.5較1.4添加了LDAP的支持，並修復了不少Bug，但從整體架構來講，沒有什麼變化。
3. 增量版本：通常表示重大Bug的修復，例如項目發佈了1.4.0版本以後後，發現了個影響功能的重大Bug，則應該快速發佈一個修復了Bug的1.4.1版本。
4. 里程碑版本：顧名思義，這每每指某一個版本的里程碑。例如， Maven3 已經發布了不少里程碑版本，如 3.0-alpha-一、3.0-alpha-二、3.0-beta-1 等。這樣的版本與正式的 3.0 相比，每每表示不是很是穩定，還須要不少測試。

須要注意的是，不是每一個版本號都必須擁有這四個部分。通常來講，主版本和次版本都會聲明，但增量版本和里程碑就不必定了。例如，像 3.8 這樣的版本沒有增量和里程碑 2.0-bea-l 沒有增量。但咱們不會看到有人省略次版本，簡單地給給出主版本顯然是不夠的。

當用戶在聲明依賴或插件未聲明版本時， Maven 就會根據上述的版本號約定自動解析最新版本。這個時候候就須要對版本號進行排序序。對於主版本、次版本和增量版原本說，比較是基於數字的，所以 1.5 > 1.4 > 1.3.11 > 1.3.9。而對於里程碑版本， Maven 則只進行簡單的字符串比較，所以會獲得 1.2-beta-3 > 1.2-beta-11 的結果。這一點須要留意。

2. 主幹、標籤與分支

使用版本控制工具時咱們都會遇到主幹(trunk)、標籤(tag)和 分支(branch)的概念。這裏再詳細將這幾個概念闡述一下，由於理解它們是理解 Maven 版本管理的基礎。

1. 口主幹：項目開發代碼的主體，是從項目開始直到當前都處於活動的狀態。從這裏能夠得到項目最新的源代碼以及幾乎全部的變動歷史。
2. 分支：從主幹的某個點分離出來的代碼拷貝，一般能夠在不影響主幹的前提下在這裏進行重大 Bug 的修復、或者作一些實驗性質的開發，若是分支達到了預期的目的，一般發生在這裏的變動公被合併(merge)主幹中。
3. 標籤：用來標識主幹或者分支的某個點的狀態，以表明項目的某個穩定狀態，這一般就是版本發佈時的狀態。

下圖下方最長的箭頭表示示項項目的主幹，項目最初的版本是 1.0.0-SNAPSHOT，通過段時間的開發後，1.0.0 版本發佈，這個時候就須要打一個標籤，圖中用一個長條表示。而後項目進入1.1.0-SNAPSHOT 狀態態，大量的開發工做都完成在主幹中，添加了一些新特性並修復了不少 Bug 以後，項目 1.1.0 發佈，一樣，這時候須要打另外一個標籤。發佈事後，項目進人 1.2.0- SNAPSHOT 階段，可這個時候用戶報告 1.1.0 版本有一個重大的 Bug，需須要儘快修復，咱們不能在主幹中修 Bug，由於主幹有太多的變化，沒法在短期內測試完畢併發布，咱們也不能中止1.2.0- SNAPSHOT 的開發，所以這時候能夠基於 1.1.0 建立一個 1.1.1-SNAPSHOT 的分支，在這裏進行 Bug 修復，而後爲用戶發佈一個 1.1.1 增量版本，同時打上標籤。固然，還不能忘了把 Bug 修復涉及的變動合併到 1.2.0-SNAPSHOT 的主幹中。主幹在開發一段時間以後，發佈 1.2.0 版本，而後進入到新版本 1.3.0-SNAPSHOT 的開發過程當中。

圖 2 展現的是一個典型的項目版本變化過程，這裏涉及了快照版與發佈版之間的切換、 Maven 版本號約定的應用，以及版本控制系統主幹、標籤和分支的使用。這其實也是一個不成文的行業標準，理解這個過程以後，不只僅可以更方便地學習開源項目，也能對項目的版本管理更加標準和清晰。

3. 自動化版本發佈

本章前幾節已經詳細介紹了版本發佈時所須要完成的工做，讀者若是願意，則徹底能夠手動地執行這些操做，檢查是否有未提交代碼、是否有快照依賴、更新快照版至發佈版、執行 Maven 構建以及爲源代碼打標籤等若是對這一過程不是很熟悉，那麼仍是應該一步一步地操做一遍，以獲得最直觀的感覺。

當熟悉了版本發佈流程以後，就會但願藉助工具將這一流程自動化。 maven-release-plugin 就提提供了這樣的功能，只要提供一些必要的信息，它就能幫咱們完成上述全部版本發佈所涉及的操做。下面介紹如何使用 maven-release-plugin 發佈項目版本。

maven-release-plugin 主要有三個目標，它們分別爲：

• 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 須要知道版本控制系統的主幹、標籤等地址信息後才能執行相關的操做。通常配置項目的SCM 信息：

<project>
    <scm>
        <connection>scm:http://admin@localhost:8080/gitblit/r/~admin/osgi.git</connection>
        <developerConnection>scm:http://admin@localhost:8080/gitblit/r/~admin/osgi.git</developerConnection>
        <url>http://admin@localhost:8080/gitblit/r/~admin/osgi.git</url>
    </scm>
</project>

connection 元素表示一個只讀的 scm 地址，而 developerConnection 元素表示可寫的 scm 地址，ur 則表示能夠在測覽器中訪問的 scm 地址。爲了能讓 Maven 識別， connec-thon 和 developerConnection 必須以 scm 開頭，冒號以後的部分表示版本控制工具類型(這裏是git)。接下來纔是實際的 scm 地址，該例中的 connection 使用了 http 協議，而 developerConnection 則因爲涉及寫操做，使用 http 協議進行了保護。