摘要
版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：
1.主版本號：當你做了不相容的 api 修改，
2.次版本號：當你做了向下相容的功能性新增，
3.修訂號：當你做了向下相容的問題修正。
簡介
在軟體管理的領域裡存在著被稱作「依賴地獄」的死亡之谷，系統規模越大，加入的包越多，你就越有可能在未來的某一天發現自己已深陷絕望之中。
在依賴高的系統中發布新版本包可能很快會成為噩夢。如果依賴關係過高，可能面臨版本控制被鎖死的風險（必須對每乙個依賴包改版才能完成某次公升級）。而如果依賴關係過於鬆散，又將無法避免版本的混亂（假設相容於未來的多個版本已超出了合理數量）。當你專案的進展因為版本依賴被鎖死或版本混亂變得不夠簡便和可靠，就意味著你正處於依賴地獄之中。
作為這個問題的解決方案之一，我提議用一組簡單的規則及條件來約束版本號的配置和增長。這些規則是根據（但不侷限於）已經被各種封閉、開放原始碼軟體所廣泛使用的慣例所設計。為了讓這套理論運作，你必須先有定義好的公共 api 。這可以透過檔案定義或**強制要求來實現。無論如何，這套 api 的清楚明了是十分重要的。一旦你定義了公共 api，你就可以透過修改相應的版本號來向大家說明你的修改。考慮使用這樣的版本號格式：x.y.z （主版本號.次版本號.修訂號）修復問題但不影響api 時，遞增修訂號；api 保持向下相容的新增及修改時，遞增次版本號；進行不向下相容的修改時，遞增主版本號。
我稱這套系統為「語義化的版本控制」，在這套約定下，版本號及其更新方式包含了相鄰版本間的底層**和修改內容的資訊。
版本管理規範
1 目的 標識 控制和追蹤軟體開發和實施過程中產生的各種軟體產品版本。2 適用範圍 適用於大運會專案所有軟體源 產品版本的管理。3 職責 3.1 測試管理 確保專案版本按照正確的版本管理規範執行和使用。3.2 配置管理員 負責定期檢查各專案對版本管理規範的執行度 根據發展需要對規範進行完善。3.3 ...
版本管理規範
版本管理規範 主要分為4個分支，dev，test，master,release dev用於本地開發 test用於發布測試環境 master 主線 庫 release分支，代表發布的線上版本 開發人員在dev分支上開發，開發完成需要發布到測試環境的時候，合併 到test分支，然後將test分支 發布到...
版本管理規範
專案 產品 大版本管理及分支策略 產品內部功能特性迭代的節奏以及版本管理 以產品為基礎各個專案的版本管理 產品自身的 分支管理方法，以不同產品版本為基礎的各個專案的 版本管理 業務微服務版本管理 產品或者專案是由多個業務微服務組成的，業務微服務的版本管理主要關注微服務本身功能特性的迭代 服務端api...