以下規約根據實際開發經驗及參考阿里巴巴java開發手冊而成，總體的設計方向如下，具體可根據實際情況做靈活變化。
groupId
GroupID 格式：com.{公司/BU }.業務線 [.子業務線]，最多 4 級。
說明： {公司/BU} 例如：alibaba/taobao/tmall/aliexpress 等 BU 一級；子業務線可選。
正例：com.taobao.jstorm 或 com.alibaba.dubbo.register
artifactId
ArtifactID 格式：產品線名-模塊名。語義不重複不遺漏，先到中央倉庫去查證一下。
正例：dubbo-client / fastjson-api / jstorm-tool
version
這裏需要先了解一下版本命名規則：一個典型的版本，一般包含如下 4 個信息：主版本號.次版本號.修訂號.版本限定符。
1） 主版本號：產品方向改變，或者大規模 API 不兼容，或者架構不兼容升級。
2） 次版本號：保持相對兼容性，增加主要功能特性，影響範圍極小的 API 不兼容修改。
3） 修訂號：保持完全兼容性，修復 BUG、新增次要功能特性等。
說明：注意起始版本號必須爲：1.0.0，而不是 0.0.1 正式發佈的類庫必須先去中央倉庫進 行查證，使版本號有延續性，正式版本號不允許覆蓋升級。如當前版本：1.3.3，那麼下一個 合理的版本號：1.3.4 或 1.4.0 或 2.0.0 。版本範圍有一個上界和下界，可以方括號 [] 或者圓括號 () 表示。方括號代表上下界的閉區間，圓括號代表上下界的開區間。
例如：“[1.1.6.RELEASE,1.3.0.M1)”代表所有從 1.1.6.RELEASE 到 1.3.0.M1 之間所有的版本（包含 1.1.6.RELEASE ，但不包含 1.3.0.M1 ）。
同時，可以使用單一版本號作爲版本範圍，例如“1.2.0.RELEASE”。單一版本號的版本範圍代表“從這個版本以及之後的所有版本”。
如果需要使用“最新的 Release 版本”的概念，可以使用一個字母x代表具體的版本號。
例如： 1.4.x.BUILD-SNAPSHOT 代表 1.4.x 的最新快照版本。
再比如：如果需要表達，從 1.1.0.RELEASE 到 1.3.x 之間的所有版本，可以用[1.1.0.RELEASE,1.3.x.RELEASE]來表達。
4） 版本限定符
另外，版本限定符也是有順序的（升序）：
-
M：里程碑版本
-
RC：發佈候選版本
-
RELEASE：發佈版本
-
BUILD-SNAPSHOT：爲開發構建的快照版本
所以快照版本是所有限定符裏優先級最高的。假設某個組件需要 Spring Boot 的最新版本，可以使用 1.5.x.BUILD-SNAPSHOT (假設 1.5 版是 Spring Boot 的最新版本)。
最後，版本範圍中討論的版本，指的都是 Spring Boot的版本，而不是組件自己的版本。
版本限定符
BUILD-SNAPSHOT：
爲開發構建的快照版本
Alpha：
Alpha是內部測試版,一般不向外部發布,會有很多Bug.除非你也是測試人員,否則不建議使用.是希臘字母的第一位,表示最初級的版本，alpha 就是α，beta 就是β ，alpha 版就是比
beta還早的測試版，一般都是內部測試的版本。
Beta:
該版本相對於α版已有了很大的改進，消除了嚴重的錯誤，但還是存在着一缺陷，需要經過多次測試來進一步消除。這個階段的版本會一直加入新的功能。
M：
里程碑版本
RC：(Release Candidate)
Candidate是候選人的意思，用在軟件上就是候選版本。Release.Candidate.就是發行候選版本。和Beta版最大的差別在於Beta階段會一直加入新的功能，但是到了RC版本，幾乎
就不會加入新的功能了，而主要着重於除錯! RC版本是最終發放給用戶的最接近正式版的版本，發行後改正bug就是正式版了，就是正式版之前的最後一個測試版。
GA：（general availability）
比如：Apache Struts 2 GA這是Apache Struts 2首次發行穩定的版本，GA意味着General Availability，也就是官方開始推薦廣泛使用了。
Release:
該版本意味“最終版本”，在前面版本的一系列測試版之後，終歸會有一個正式版本，是最終交付用戶使用的一個版本。該版本有時也稱爲標準版。一般情況下，Release不會以單詞形式出現在軟件封面上，取而代之的是符號(R)。
安全規約
1. 【強制】線上應用不要依賴 SNAPSHOT 版本（安全包除外）。 說明：不依賴 SNAPSHOT 版本是保證應用發佈的冪等性。另外，也可以加快編譯時的打包構建。
2. 【強制】二方庫的新增或升級，保持除功能點之外的其它 jar 包仲裁結果不變。如果有改變， 必須明確評估和驗證，建議進行 dependency:resolve 前後信息比對，如果仲裁結果完全不一 致，那麼通過 dependency:tree 命令，找出差異點，進行<excludes>排除 jar 包。
3. 【強制】二方庫裏可以定義枚舉類型，參數可以使用枚舉類型，但是接口返回值不允許使用枚 舉類型或者包含枚舉類型的 POJO 對象。
4. 【強制】依賴於一個二方庫羣時，必須定義一個統一的版本變量，避免版本號不一致。 說明：依賴 springframework-core,-context,-beans，它們都是同一個版本，可以定義一 個變量來保存版本：${spring.version}，定義依賴的時候，引用該版本。
5. 【強制】禁止在子項目的 pom 依賴中出現相同的 GroupId，相同的 ArtifactId，但是不同的 Version。 說明：在本地調試時會使用各子項目指定的版本號，但是合併成一個 war，只能有一個版本號 出現在最後的 lib 目錄中。可能出現線下調試是正確的，發佈到線上卻出故障的問題。
6. 【推薦】所有 pom 文件中的依賴聲明放在<dependencies>語句塊中，所有版本仲裁放在 <dependencyManagement>語句塊中。 說明：<dependencyManagement>裏只是聲明版本，並不實現引入，因此子項目需要顯式的聲 明依賴，version 和 scope 都讀取自父 pom。而<dependencies>所有聲明在主 pom 的 <dependencies>裏的依賴都會自動引入，並默認被所有的子項目繼承。
7. 【推薦】二方庫不要有配置項，最低限度不要再增加配置項。
8. 【參考】爲避免應用二方庫的依賴衝突問題，二方庫發佈者應當遵循以下原則： 1）精簡可控原則。移除一切不必要的 API 和依賴，只包含 Service API、必要的領域模型對 象、Utils 類、常量、枚舉等。如果依賴其它二方庫，儘量是 provided 引入，讓二方庫使用 者去依賴具體版本號；無 log 具體實現，只依賴日誌框架。 2）穩定可追溯原則。每個版本的變化應該被記錄，二方庫由誰維護，源碼在哪裏，都需要能 方便查到。除非用戶主動升級版本，否則公共二方庫的行爲不應該發生變化
- 一方庫: 本工程內部子項目模塊依賴的庫（jar 包）
- 二方庫: 公司內部發布到中央倉庫，可供公司內部其它應用依賴的庫（jar 包）
- 三方庫: 公司之外的開源庫（jar 包）