在Maven的世界中，任何一個項目或者構件都必須有自己的版本。版本的值可能是1.0.0、1.3-alpha-4、2.0、2.1-SNAPSHOT或者2.1-20091214.221414-13。其中，1.0.0、1.3-alpha-4和2.0是穩定的發佈版本，而2.1-SNAPSHOT和2.1-20091214.221414-13是不穩定的快照版本。
Maven為什麼要區分發佈版和快照版呢？簡單的1.0.0、1.2、2.1等不就夠了嗎？為什麼還要有2.1-SNAPSHOT，甚至是長長的2.1-20091214.221414-13？試想一下這樣的情況，小張在開發模塊A的2.1版本，該版本還未正式發佈，與模塊A一同開發的還有模塊B，它由小張的同事季MM開發，B的功能依賴於A。在開發的過程中，小張需要經常將自己最新的構建輸出，交給季MM，供她開發和集成調試，問題是，這個工作如何進行呢？
1.方案一
讓季MM自己簽出模塊A的源碼進行構建。這種方法能夠確保季MM得到模塊A的最新構件，不過她不得不去構建模塊A。多了一些版本控制和Maven操作還不算，當構建A失敗的時候，她會是一頭霧水，最後不得不找小張解決。顯然，這種方式是低效的。
2.方案二
重複部署模塊A的2.1版本供季MM下載。雖然小張能夠保證倉庫中的構件是最新的，但對於Maven來說，同樣的版本和同樣的坐標就意味著同樣的構件。因此，如果季MM在本機的本地倉庫包含了模塊A的2.1版本構件，Maven就不會再對照遠程倉庫進行更新。除非她每次執行Maven命令之前，清除本地倉庫，但這種要求手工干預的做法顯然也是不可取的。
3.方案三
不停更新版本2.1.1、2.1.2、2.1.3……。首先，小張和季MM兩人都需要頻繁地更改POM，如果有更多的模塊依賴於模塊A，就會涉及更多的POM更改；其次，大量的版本其實僅僅包含了微小的差異，有時候是對版本號的濫用。
Maven的快照版本機制就是為了解決上述問題。在該例中，小張只需要將模塊A的版本設定為2.1-SNAPSHOT，然後發佈到私服中，在發佈的過程中，Maven會自動為構件打上時間戳。比如2.1-20091214.221414-13就表示2009年12月14日22點14分14秒的第13次快照。有了該時間戳，Maven就能隨時找到倉庫中該構件2.1-SNAPSHOT版本最新的文件。這時，季MM配置對於模塊A的2.1-SNAPSHOT版本的依賴，當她構建模塊B的時候，Maven會自動從倉庫中檢查模塊A的2.1-SNAPSHOT的最新構件，當發現有更新時便進行下載。默認情況下，Maven每天檢查一次更新（由倉庫配置的updatePolicy控制，見第6.4節），用戶也可以使用命令行-U參數強制讓Maven檢查更新，如mvn clean install-U。
基於快照版本機制，小張在構建成功之後才能將構件部署至倉庫，而季MM可以完全不用考慮模塊A的構建，並且她能確保隨時得到模塊A的最新可用的快照構件，而這一切都不需要額外的手工操作。
當項目經過完善的測試後需要發佈的時候，就應該將快照版本更改為發佈版本。例如，將2.1-SNAPSHOT更改為2.1，表示該版本已經穩定，且只對應了唯一的構件。相比之下，2.1-SNAPSHOT往往對應了大量的帶有不同時間戳的構件，這也決定了其不穩定性。
快照版本只應該在組織內部的項目或模塊間依賴使用，因為這時，組織對於這些快照版本的依賴具有完全的理解及控制權。項目不應該依賴於任何組織外部的快照版本依賴，由於快照版本的不穩定性，這樣的依賴會造成潛在的危險。也就是說，即使項目構建今天是成功的，由於外部的快照版本依賴實際對應的構件隨時可能變化，項目的構建就可能由於這些外部的不受控制的因素而失敗。