版本號管理規則

 

一. 項目凡涉及文檔及代碼均要求按照版本號演進的方式，去推動工做結果的提交，在項目管理系統中此類任務主題須要註明版本號；
如：用戶註冊(jixiao360-3.1.12)

二. 代碼任務，提交git代碼版本規則：
1. 版本號整體命名：項目名-主版本號.次版本號.修訂版本號-開發階段號
如：jixiao360-3.1.12-rc1

2. 主版本號：開發時直接創建分支，說明是全局功能（重大）的改進，在項目管理系統中會創建項目或子項目，通常創建子項目；
當功能模塊有較大的變更，好比增長模塊或是總體架構發生變化。此版本號由項目決定是否修改。
由項目決定修改的意思，是指至少兩個以上項目決策人員敲定。

3. 次版本號：局部功能的改進，在項目管理系統中會創建任務，通常創建總任務，屬於管理型任務；
相對於主版本號而言，次版本號的升級對應的只是局部的變更，但該局部的變更形成程序和之前版本不能兼容，
或者對該程序之前的協做關係產生了破壞，或者是功能上有大的改進或加強。此版本號由項目決定是否修改。

4. 修訂版本號: 當前開發任務的版本，有具體的開發人員，屬於執行型任務；
通常是Bug的修復或是一些小的變更或是一些功能的擴充，要常常發佈修訂版，修復一個嚴重 Bug便可發佈一個修訂版。
此版本號由項目經理決定是否修改。

5. 更細節子任務不參與版本號的變動。

6. 開發階段號：
1)model(簡寫：m)： 模型階段。
此階段表示該軟件僅僅是一個假頁面連接，一般包括全部的功能和頁面佈局，
可是頁面中的功能都沒有作完整的實現，只是作爲總體網站的一個基礎架構。

2)alpha(簡寫：a): 內測階段。
提交軟件的初級版本，表示該軟件在此階段以實現軟件功能爲主，一般只在軟件開發者內部交流，
通常而言，該版本軟件的Bug較多，須要繼續修改，是測試版本。測試 人員提交Bug經開發人員
修改確認以後，發佈到測試網址讓測試人員測試，此時可將軟件版本標註爲alpha版。

3)beta(簡寫：b): 公測階段。
相對於Alpha版已經有了很大的進步，消除了嚴重錯誤，但還須要通過屢次測試來進一步消除，此版本主要的修改對象是軟件的UI。
修改的的Bug 經測試人員測試確認後可發佈到外網上，此時可將軟件版本標註爲 beta版。

4)release candidate(簡寫：rc): 候選階段。
該版本已經至關成熟了，基本上不存在致使錯誤的Bug，與即將發行的正式版本相差無幾。

5)release(簡寫：r): 官方發佈階段。
該版本意味「最終版本」，在前面版本的一系列測試版以後，終歸會有一個正式的版本，是最終交付用戶使用的一個版本。該版本有時也稱標準版。

7. 參照舉例：

3.1.01-m （model)
3.1.01-a （alpha 內測)
3.1.01-b2 (beta with some bug fixes 公測)
3.1.01-rc3 (release candidate 候選)
3.1.01-r (commercial distribution 官方發佈)
3.1.01-r5 (commercial distribution with many bug fixes 修正bug以後的官方發佈版)

 

8..版本發佈週期：
1）非緊急狀況：
首先由測試人員測試並提交Bug，其次開發人員會盡可能在當天修復Bug並在次日發佈該版本的alpha版，
而後由測試人員測試驗證關閉Bug以後在第三天會發布該版本的 beta 版。

2）緊急狀況： 若是Bug比較緊急可跳過通常流程，由開發人員儘快修復Bug，測試確認以後直接發佈該版本的 beta版。