軟件版本號規範

軟件版本階段說明

  • Base版: 此版本表示該軟件僅僅是一個假頁面鏈接,通常包括所有的功能和頁面佈局,但是頁面中的功能都沒有做完整的實現,只是做爲整體網站的一個基礎架構。
  • Alpha版: 此版本表示該軟件在此階段主要是以實現軟件功能爲主,通常只在軟件開發者內部交流,一般而言,該版本軟件的Bug較多,需要繼續修改。
  • Beta版: 該版本相對於α版已有了很大的改進,消除了嚴重的錯誤,但還是存在着一些缺陷,需要經過多次測試來進一步消除,此版本主要的修改對像是軟件的UI。
  • RC版: 該版本已經相當成熟了,基本上不存在導致錯誤的BUG,與即將發行的正式版相差無幾。
  • Release版: 該版本意味“最終版本”,在前面版本的一系列測試版之後,終歸會有一個正式版本,是最終交付用戶使用的一個版本。該版本有時也稱爲標準版。一般情況下,Release不會以單詞形式出現在軟件封面上,取而代之的是符號(R)。

版本命名規範

軟件版本號由四部分組成,第一個1爲主版本號,第二個1爲子版本號,第三個1爲階段版本號,第四部分爲日期版本號加希臘字母版本號

主版本號 次版本號 增量版本號 里程碑版本號

希臘字母版本號共有5種,分別爲:base、alpha、beta、RC、release。例如:1.1.1.051021_beta。

版本號定修改規則:

  • 主版本號(1):當功能模塊有較大的變動,比如增加多個模塊或者整體架構發生變化。此版本號由項目決定是否修改。
  • 子版本號(1):當功能有一定的增加或變化,比如增加了對權限控制、增加自定義視圖等功能。此版本號由項目決定是否修改。
  • 階段版本號(1):一般是 Bug 修復或是一些小的變動,要經常發佈修訂版,時間間隔不限,修復一個嚴重的bug即可發佈一個修訂版。此版本號由項目經理決定是否修改。
  • 日期版本號(051021):用於記錄修改項目的當前日期,每天對項目的修改都需要更改日期版本號。此版本號由開發人員決定是否修改。
  • 希臘字母版本號(beta):此版本號用於標註當前版本的軟件處於哪個開發階段,當軟件進入到另一個階段時需要修改此版本號。此版本號由項目決定是否修改。

文件命名規範

文件名稱由四部分組成:第一部分爲項目名稱,第二部分爲文件的描述,第三部分爲當前軟件的版本號,第四部分爲文件階段標識加文件後綴,例如:XXX服務平臺-測試報告-1.1.1.051021_beta_b.xls
如果是同一版本同一階段的文件修改過兩次以上,則在階段標識後面加以數字標識,每次修改數字加1,如:XXX服務平臺-測試報告-1.1.1.051021_beta_b1.xls.

軟件的每個版本中包括11個階段,詳細階段描述如下

階段名稱 階段標識
需求控制 a
設計階段 b
編碼階段 c
單元測試 d
單元測試修改 e
集成測試 f
集成測試修改 g
系統測試 h
系統測試修改 i
驗收測試 j
驗收測試修改 k

Maven的Snapshot版本與Release版本

  1. Snapshot版本代表不穩定、尚處於開發中的版本

  2. Release版本則代表穩定的版本

什麼情況下該用SNAPSHOT?

協同開發時,如果A依賴構件B,由於B會更新,B應該使用SNAPSHOT來標識自己。這種做法的必要性可以反證如下:

a.如果B不用SNAPSHOT,而是每次更新後都使用一個穩定的版本,那版本號就會升得太快,每天一升甚至每個小時一升,這就是對版本號的濫用。
b.如果B不用SNAPSHOT, 但一直使用一個單一的Release版本號,那當B更新後,A可能並不會接受到更新。因爲A所使用的repository一般不會頻繁更新release版本的緩存(即本地repository),所以B以不換版本號的方式更新後,A在拿B時發現本地已有這個版本,就不會去遠程Repository下載最新的B

不用Release版本,在所有地方都用SNAPSHOT版本行不行?

不行。正式環境中不得使用snapshot版本的庫。 比如說,今天你依賴某個snapshot版本的第三方庫成功構建了自己的應用,明天再構建時可能就會失敗,因爲今晚第三方可能已經更新了它的snapshot庫。你再次構建時,Maven會去遠程repository下載snapshot的最新版本,你構建時用的庫就是新的jar文件了,這時正確性就很難保證了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章