最近正在研究如何命名軟體的版本編號，比較符合現在常用的命名方式。當然版本號可以隨意訂，但是使用了一個大家通用的規則的話，其他人也比較容易從版本號上看出了不同版本之間的變化有多大。以下分享我所瞭解到的命名規則。
命名規則
首先，在開始分享之前，先提供一份參考文件。基本上我就是遵照這份文件的所定義的規則。
Semantic Versioning: http://semver.org/
這份文件有提供多種不同的語言供大家閱讀，我看了一下中文的翻譯也沒什麼問題，應該可以安心食用XD
那麼接下來就大致介紹一下主要的規則。
版本編號格式
版本編號必須要依照以下格式命名：
1 | [主版本號].[次版本號].[修訂版本號] |
以上每個編號都是 >= 0 的數字，下面就是一個符合規則的版本編號：
1 | 1.0.3 |
每次一發佈新版本的時候就遞增其中一個編號。
每個編號遞增的時機
- 主版本號：軟體有重大更新的時候遞增，重大更新通常是指功能與介面都有大幅度變動的時候。
- 次版本號：軟體發佈新功能，但是並不會大幅影響到整個軟體的時候遞增。
- 修訂版本號：通常是在軟體有 bug，發布 bug 的修正版時遞增。
有些版本編號除了上述三者之外，還會有「建置版本號」。也就是只要每次建置一次軟體就會遞增一次，有時候甚至會使用建置的日期或時間來代表。不過已經很少人在用了。
版本號的比較
比較的規則很簡單，就是從最左邊的數字開始比。比較大的就是比較新的版本。
如果數字一樣的話，就比下一個數字。
以下是一個比較的例子：
1 | 1.0.0 < 1.0.1 < 1.1.0 < 1.2.0 < 1.4.5 < 2.0.0 < 2.1.12 < 2.3.2 < 3.0.0 ... |
正式版之前的測試版本編號
有些軟體在發布正式版本之前，會先發布測試版本給大眾使用。測試版本不保證沒有任何 bug 或者功能完善。
通常測試版的 主版本號 會是 0，例如 0.3.1 就是一個測試版本。
而一般會使用 0.1.0 當作測試版的初始版本號。
提醒
除了以上規則之外，還有些規則的細節沒有提及。如果有興趣的話可以直接看看最上面提供的文件。
命名範例
以下分別以「線上遊戲」與「函式庫」兩者為例。
線上遊戲
假設現在有款 RPG 線上遊戲叫做 小山貓 online，一開始正式發佈的版本號是：
1 | 1.0.0 |
接著推出一段時間之後，為了增加遊戲的豐富性，新增了一些新的關卡與任務，此時 次版本號 有可能就會遞增：
1 | 1.1.0 |
新增了新功能不久，有玩家回報在解任務時會卡住，沒辦法繼續。工程師檢查之下發現是 bug，立即修正。因此發佈了 bug 修正版，修正版本號 遞增：
1 | 1.1.1 |
過了一段時間，又發布了新的關卡與任務，因此 次版本號 再度遞增，而 修正版本號 歸零：
1 | 1.2.0 |
就這樣持續了一段時間。隨著時間的推進，現有的地圖與故事似乎無法滿足玩家的需求，因此遊戲公司撰寫了新故事與製作了新地圖，推出了 小山貓的遠征之旅 大改版！
這個時候，遊戲出現了重大更新，所以 主版本號 很有可能就會遞增，後面的版本號則歸零：
1 | 2.0.0 |
這是一個線上遊戲可能的版本編號命名時機與流程。
函式庫
函式庫的狀況與遊戲不同，因為使用函式庫的人通常是開發其他程式的工程師，所以版本號遞增的時機也會不太一樣。
假設我寫了一個 小山貓函式庫，只要呼叫一個 catMeow() 這個函式，電腦喇叭就會發出貓咪的叫聲。
而版本編號一開始可能訂為：
1 | 1.0.0 |
此時我心血來潮，突然想要新增一個新的函式（新功能），catAnimate() 函式，呼叫之後程式畫面中就會出現貓咪動畫。
次版本號 可能就會遞增：
1 | 1.1.0 |
我突然接到其他開發者來信，他說他們呼叫了新的 catAnimate() 之後，沒有出現貓，而是出現狗！
這真是太嚴重了！必須要馬上修正這個 bug！因此我發布了一個修訂版本，且遞增了 修訂版本號：
1 | 1.1.1 |
過了一段時間之後，我覺得現在這個 API 設計不好，我想用物件導向的方式重寫。
在重寫之後，任何人使用舊的功能之前，必須要先使用 new Cat() 建立一個貓咪物件，然後分別呼叫 cat.meow() 與 cat.animate() 才能使用之前的功能。
這個改變影響到了許多已經寫好程式的開發者，因為他們必須要把所有使用到 小山貓函式庫 的地方全部改成新的寫法。
為了因應這種重大更新，此時必須要遞增 主版本號：
1 | 2.0.0 |
小結
大家應該可以注意到一件事情，通常遊戲的重大更新對玩家來說都是一個令人開心的事件，但是函式庫的重大更新（主版本號遞增）通常對開發者來說就代表著：「Fxxk！程式又要大修了！」
開發者會視情況來決定是否要使用大更新後的函式庫。有很多情況是，開發者仍使用舊的版本（像是 小山貓函式庫 的 1.1.1 版），而只有開發新程式的時候才會使用最新的版本。
例如 OpenGL 某次重大更新之後，大大地修改了繪圖的流程與方式，很多舊的函式都不能呼叫了，因此到現在還是很多人使用舊版。另外像是 Python 3 的更新也改掉了很多語法的使用方式。
總結
這邊提供的只是一種目前常看到的命名規則。當然要自己定義自己的規則也不是不行，像是直接用發布日期來當版本號，只是其他人就無法使用這種常用的邏輯來判斷版本號的意義。此時最好提供一份文件說明這些版本號的意義。
另外，有些軟體在測試期間，可能會使用不同規則的命名方式。
例如從 這份下載清單 可以看到， Minecraft 在測試期間的版本編號，是在前面分別加上 a 代表 alpha 版，加上 b 代表 beta 版。正式版本再使用類似這裡分享的規則來命名。
我個人是建議就遵照最上方文件提供的規則就好，使用一個大多數人都使用的規則並沒有什麼壞處。