概述
版本管理主要用於對執行程式的版本追蹤,從而可以管理線上服務的執行版本,避免各個版本的服務程式混淆.這裡通常的做法為在程式中埋入版本標誌,同時該版本號會對應到git上的tag或release版本.從而對線上服務更改有一個更全面的資訊說明.這裡將介紹基於GNU風格一種版本命名方式.
1 版本號命名格式
主版本號 . 子版本號 [. 修正版本號 [. 編譯版本號 ]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]] 示例 : 1.2.1, 2.0, 5.0.0 build-13124
- Major
具有相同名稱但不同主版本號的程式集不可互換。例如，這適用於對產品的大量重寫，這些重寫使得無法實現向後相容性。
- Minor
如果兩個程式集的名稱和主版本號相同，而次版本號不同，這指示顯著增強，但照顧到了向後相容性。例如，這適用於產品的修正版或完全向後相容的新版本。
- Build
內部版本號的不同表示對相同源所作的重新編譯。這適合於更改處理器、平臺或編譯器的情況。
- Revision
名稱、主版本號和次版本號都相同但修訂號不同的程式集應是完全可互換的。這適用於修復以前釋出的程式集中的安全漏洞。
程式集的只有內部版本號或修訂號不同的後續版本被認為是先前版本的修補程式 (Hotfix) 更新。
2. 版本號管理策略
1). 專案初版本時，版本號可以為 0.1 或 0.1.0, 也可以為 1.0 或 1.0.0.
2). 當專案在進行了區域性修改或 bug 修正時，主版本號和子版本號都不變，修正版本號加 1；
3). 當專案在原有的基礎上增加了部分功能時，主版本號不變，子版本號加 1，修正版本號復位為 0，因而可以被忽略掉；
4). 當專案在進行了重大修改或區域性修正累積較多，而導致專案整體發生全域性變化時，主版本號加 1；
5). 另外，編譯版本號一般是編譯器在編譯過程中自動生成的，我們只定義其格式，並不進行人為控制。
3. 專案中埋入版本資訊
針對每個服務,新建一個version的包用於版本管理,手動更改編譯指令碼中的版本號.且該版本號必須和gitlab上的版本號一一對應. 當執行二進位制程式的並輸入-v引數時則輸出該程式的版本號,不輸入任何引數時則執行程式.
4.示例
示例見https://github.com/g4zhuj/ver…
使用時使用build指令碼編譯即可生成帶有提交資訊的程式,需要根據程式修改build指令碼中引數.
執行後產生的結果如下:
./example -v
Version: 0.0.1
Git commit: de07491
Go version: go version go1.6.2 linux/amd64
Build time: 2017-05-11 16:20:27