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

例如：
（內）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

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

基本主要會分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號。
因為某個死傢伙改了一點就儲存推上。差點沒氣死就是了。

語意化版本 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