6.5節談到，為了方便團隊的合作，在項目開發的過程中，大家都應該使用快照版本，Maven能夠很智能地處理這種特殊的版本，解析項目各個模塊最新的「快照」。快照版本機制促進團隊內部的交流，但是當項目需要對外發佈時，我們顯然需要提供非常穩定的版本，使用該版本應當永遠只能夠定位到唯一的構件，而不是像快照版本那樣，定位的構件隨時可能發生變化。對應地，我們稱這類穩定的版本為發佈版。項目發佈了一個版本之後，就進入下一個開發階段，項目也就自然轉換到新的快照版本中。
版本管理關心的問題之一就是這種快照版和發佈版之間的轉換。項目經過了一段時間的1.0-SNAPSHOT的開發之後，在某個時刻發佈了1.0正式版，然後項目又進入了1.1-SNAPSHOT的開發，這個版本可能添加了一些有趣的特性，然後在某個時刻發佈1.1正式版。項目接著進入1.2-SNAPSHOT的開發。由於快照對應了項目的開發過程，因此往往對應了很長的時間，而正式版本對應了項目的發佈，因此僅僅代表某個時刻項目的狀態，如圖13-1所示。
圖13-1 快照版和發佈版之間的轉換
理想的發佈版本應當對應了項目某個時刻比較穩定的狀態，這包括源代碼的狀態以及構建的狀態，因此這個時候項目的構建應當滿足以下的條件：
·所有自動化測試應當全部通過。毫無疑問，失敗的測試代表了需要修復的問題，因此發佈版本之前應該確保所有測試都能得以正確執行。
·項目沒有配置任何快照版本的依賴。快照版本的依賴意味著不同時間的構建可能會引入不同內容的依賴，這顯然不能保證多次構建能夠生成同樣的結果。
·項目沒有配置任何快照版本的插件。快照版本的插件配置可能會在不同時間引入不容內容的Maven插件，從而影響Maven的行為，破壞構建的穩定性。
·項目所包含的代碼已經全部提交到版本控制系統中。項目已經發佈了，可源代碼卻不在版本控制系統中，甚至丟失了。這意味著項目丟失了某個時刻的狀態，因此這種情況必須避免，版本發佈的時候必須確保所有的源代碼都已經提交了。
只有上述條件都滿足之後，才可以將快照版本更新為發佈版本，例如將1.0-SNAPSHOT更新為1.0，然後生成版本為1.0的項目構件。
不過這裡還缺少一步關鍵的版本控制操作。如果你瞭解任何一種版本控制工具，如Subversion，那就應該能想到項目發佈與標籤（Tag）的關係。版本控制系統記錄代碼的每一個變化，通常這些變化都被維護在主幹（Trunk）中，但是當項目發佈的時候，開發人員就應該使用標籤記錄這一特殊時刻項目的狀態。以Subversion為例，日常的變更維護在主幹中，包含各種源碼版本r1、r2、…、r284、…。要找到某個時刻的項目狀態會比較麻煩，而使用標籤就可以明確地將某個源碼版本（也就是項目狀態）從主幹中標記出來，放到單獨的位置，這樣在之後的任何時刻，我們都能夠快速地得到發佈版本的源代碼，從而能夠比較各個版本的差異，甚至重新構建一個同樣版本的構件。
因此，將項目的快照版本更新至發佈版本之後，應當再執行一次Maven構建，以確保項目狀態是健康的。然後將這一變更提交到版本控制系統的主幹中。接著再為當前主幹的狀態打上標籤。以Subversion為例，這幾個步驟對應的命令如下：
至此，一個版本發佈的過程完成了。接下來要做的就是更新發佈版本至新的快照版本，如從1.0到1.1-SNAPSHOT。