iT邦幫忙

3

分享個人的版本號管控邏輯,拋轉引玉問題討論

分享個人的版本號管控邏輯

假如我做一個軟體,我個人管控版本號方式

  1. 版本從 0.1.0.0 版本開始
  2. 假如是單純小 bug、功能 修正進版方式,改為 0.1.0.1 版本號
  3. 假如是小功能的增加,進版改為 0.1.1.0 版本號
  4. 假如是大版本改動,進版改為 0.2.0.0 版本號
  5. 假如宣告跨世代改動,進版改為 1.0.0.0 版本號

假如是先行測試版本,版本號改為 0.1.0.0 preview
假如是公測版本,版本號改為 0.1.0.0 beta
假如是穩定版本,版本號改為 0.1.0.0 stable
假如是長期維護版本,版本號改為 0.1.0.0 (LTS)


假如前輩、版友有更好作法熱烈歡迎留言討論

4
老頭
iT邦新手 5 級 ‧ 2020-09-24 16:26:27
最佳解答

我們在管理版本時,會考量內部的版本碼及外部的版本碼。內部碼只有公司內部看得到,而外部碼則是讓用戶或者是客戶看的,通常外部碼是內部碼的子集加上版本屬性。

例如:
(內)0.0.0 build 01 << debugging & development
(內)0.0.0 build 02
   ..............
(內)0.0.0 build 17 << 穩定了,可進版
(內)0.0.1 build 00 << 它是 0.0.0 build 17 進版
(外)0.0.1 beta << 它是 0.0.1 build 00 的外部版號(並告訴客人這是 beta版)
(內)0.0.1 build 01 << debugging & development

李正群 iT邦新手 5 級 ‧ 2020-09-25 08:31:12 檢舉

原來還可以這樣,感謝分享!

2
浩瀚星空
iT邦超人 1 級 ‧ 2020-09-24 21:19:37

以前用的版本號定義給你參考。
不過先說,這是我個人決定定義的方式。並非是參考任何網路上的建議。
所以說錯了不要怪我

基本主要會分5格 0.0.0.0.0

1.主系統變更版本號:
一般有大型改版,或是修正的功能主題已超過20以上,就會決定更新版本

2.新功能加入版本號:
加新功能有變動請求或使用的方式+1

3.功能更新修正版本號
未變動使用、請求方式,單純優化改良+1

4.bug處理版本號
bug處理+1

5.內部作業版本號
內部作業儲存版本號。(一般跟隨控版程式處理)

除了4跟5不會讓客戶知道。只會給相關人員知道。
對外來說就是只有 1.0.0
對內來說則會看到 1.0.0.0.0

正常來說當4跟5處理一個階段後。就會全數變0。第3個就會+1

這是以前的控版版號。
偷偷說,曾經有過第5個達到1000號。
因為某個死傢伙改了一點就儲存推上。差點沒氣死就是了。

李正群 iT邦新手 5 級 ‧ 2020-09-25 08:31:23 檢舉

感謝前輩分享!!

0
wolfwang
iT邦新手 3 級 ‧ 2020-09-25 18:03:02

語意化版本 2.0.0
https://semver.org/lang/zh-TW/

Laravel 6.0 之後改採語意化版本 2.0.0

1. Semantic Versioning語義化版本控制
Semantic Versioning 2.0.0提供多種語言可供閱讀,文件簡介的部分直接了當的說明目的是解決相依性地獄(dependency hell)可能發生的問題,無論相依性高或低都會造成混亂,要如何判斷你正面臨這種狀況?
當你專案的進展因為版本相依被鎖死或版本混亂變得不夠簡便和可靠,就意味著你正處於相依性地獄之中。

使用標準的版號格式:X.Y.Z(主版號.次版號.修訂號)
eg:修復問題但不影響 API 時,遞增修訂號;API 保持向下相容的新增及修改時,遞增次版號;進行不向下相容的修改時,遞增主版號。

出處:https://ithelp.ithome.com.tw/articles/10220541

我要發表回答

立即登入回答