1. 概述
當命名發佈版本時，通常使用語義版本控制（Semantic Versioning）。例如，以下格式的版本規則適用於 MAJOR.MINOR.REVISION：
- MAJOR：主要功能和潛在的破壞性變更
- MINOR：向後兼容的功能
- REVISION：向後兼容的修復和改進
與語義版本控制一起，項目通常使用標籤來進一步明確特定發佈版本的狀態。實際上，通過使用這些標籤，我們可以提供有關構建生命週期或製品發佈位置的線索。
在本文中，我們將研究主要 Spring 項目採用的版本命名方案。
2. Spring 框架和 Spring Boot
除了語義版本控制之外，Spring 框架和 Spring Boot 使用以下標籤：
- BUILD-SNAPSHOT
- M[數字]
- RC[數字]
- RELEASE
BUILD-SNAPSHOT 是當前的開發版本。 Spring 團隊每天構建此 Artifact 並將其部署到 https://repo.spring.io/ui/native/snapshot。
里程碑版本 (M1, M2, M3, …) 標誌着發佈過程中的一個重要階段。 當開發迭代完成後，團隊構建此 Artifact 並將其部署到 https://repo.spring.io/ui/native/milestone。
候選發佈版本 (RC1, RC2, RC3, …) 是在構建最終版本之前最後的步驟。 為了減少代碼更改，在此階段應僅進行錯誤修復。 它也部署到 https://repo.spring.io/ui/native/milestone。
在發佈過程的最後，Spring 團隊會產生 RELEASE。 因此，這通常是唯一的生產就緒 Artifact。 我們可以將此版本也稱為 GA，通用可用性。
這些標籤是按字母順序排列的，以確保構建和依賴管理器正確確定一個版本是否比另一個版本新。 例如，Maven 2 將 1.0-SNAPSHOT 錯誤地認為是比 1.0-RELEASE 新的版本。 Maven 3 修復了此行為。 因此，當我們的命名方案不理想時，我們可能會遇到奇怪的行為。
3. 傘式項目
傘式項目，如 Spring Cloud 和 Spring Data，是建立在獨立但相關的子項目之上的項目。為了避免與這些子項目發生衝突，傘式項目會採用不同的命名方案。與其採用數字版本，每個發佈火車都將擁有一個特殊的名稱。
倫敦地鐵站為 Spring Cloud 的發佈名稱提供了靈感——例如，Angel、Brixton、Finchley、Greenwich 和 Hoxton。
除了上述的 Spring 標籤外，它還定義了一個服務發佈標籤（SR1、SR2…）。如果發現關鍵性 bug，就可以發佈服務發佈。
重要的是要意識到，一個 Spring Cloud 發佈版本僅與特定版本的 Spring Boot 兼容。作為參考，Spring Cloud 項目頁面 包含兼容性表。
4. 結論
如上所示，採用清晰的版本命名方案至關重要。雖然某些發佈版本，如里程碑或候選發佈版本，可能已經穩定，但我們始終應使用生產級別的 Artifacts。 您的命名方案是什麼？它相對於這個方案有什麼優勢？
