【導讀】作為嵌入式工程師，版本號管理絕不是簡單的數字編號，而是把控產品迭代節奏、定位問題根源、保障產品質量的核心抓手。嵌入式軟件升級常牽扯硬件驅動、硬件適配等關鍵環節，版本管理混亂極易引發適配沖突，讓問題溯源難上加難。本文從嵌入式開發的實際需求出發，結合具體場景講解各版本號的變更邏輯，給出可直接落地的C語言版本號定義代碼與應用示例，幫你建立一套易理解、可落地的版本號管理規范，讓嵌入式軟件迭代更有序，問題追溯更高效。
在嵌入式軟件開發里面，經常會涉及到軟件和固件的版本號管理，版本號并不只是一個簡單的編號，而是把控迭代節奏、快速查找問題根源、穩住產品質量的重要手段。
嵌入式軟件的升級，有時候會牽扯到硬件底層驅動、硬件適配等幾個方面，如果版本管理亂成了一鍋粥，就很容易會出現適配沖突，會容易找不到問題產生的源頭。
所以，搞一套容易理解并且又能科學管理軟件版本號的規則，對于嵌入式軟件開發甚至產品運維來說，都顯得非常重要！
在軟件行業里面，最常用的是四級語義化版本結構，也就是“主版本號 . 次版本號 . 修訂號 . 構建號”。
主版本號（Major）：主要用來標記互不兼容的大版本改動，一般從1開始計算。比如，某款工業網關設備軟件版本是V1.2.3.007，后來因為重新適配了CPU和設計了驅動程序，這種大變動之后，版本號要改為V2.0.0.0。
主版本號如果發生改變，就要跟很多部門同步這個更新信息，也要跟用戶描述清楚新舊版本的兼容情況。
如果是在研發階段而非量產階段，主版本號就設置為0，比如V0.1.2.345，這樣很容易直觀看出該版本還沒有量產發布。
次版本號（Minor）：對應新增功能，并且這些功能與同一個主版本號的新舊版本兼容，次版本號一般從0開始，每更新一次就代表增加了新的功能或做了重要的優化。
比如，某款傳感器的固件V2.1.1.123已經支持了藍牙通信，后來要增加Wi-Fi通信（不改動硬件），在固件開發完成之后，版本號就改為V2.2.0.1了。
需要注意的是，這次的改版只增加功能，但不能動核心模塊的接口，這樣用戶才能進行增量迭代升級，而不用折騰硬件配置。
修訂號（Patch）：主要用來修復bug，不增加新的功能，并且還需要兼容新舊的主版本號和次版本號，修訂號也是從0開始增加的，最常見的用途就是修復bug、優化性能、微調穩定性參數，等等。
比如，用戶反饋產品的藍牙通信容易斷開連接，工程師找到問題所在并修復了bug，沒有改動任何的功能模塊，這樣就可以在修訂號上進行升級，例如從V3.2.1.309升級到V3.2.2.315。
注意，更改修訂號的時候，需要在版本日志里面注明修改了哪個bug，影響范圍有多大，測試結果怎樣，方便后續繼續追溯問題。
構建號（Build）：這是在嵌入式場景里面額外增加的版本號字段，是用來標記同一個版本的不同編譯次數的，一般由腳本工具自動生成，不需要工程師手動更改。
它的主要作用是方便研發團隊內部更新測試固件，比如，某款模組第一版測試時版本號是V0.1.1.102，然后下一次構建就變成了V0.1.1.103.
構建號不影響版本的兼容性，并且只在研發團隊內部使用，在正式量產發布的時候，需要把構建號進行固定，不能出現一個正式版本對應多個構建版本的情況。
還有一點就是，對于預發布版本，可以加一個后綴來進行狀態區分，比如某款路由器固件，可以先出一個內測版本V1.1.0.123-beta給內部使用，內測完成之后再出一個V1.1.0.135-rc1候選版，最終沒有問題就發布V1.1.0.135。
在嵌入式軟件里面，通常在頭文件里面確定版本號的宏定義，這樣既能方便業務邏輯調用和日志打印，還能用來校驗固件升級。
以下是直接可用的C語言代碼，頭文件 version.h
具體應用案例，源文件 main.c
上述的示例代碼，版本號是用宏定義的方式進行編寫的，方便編譯腳本自動更新構建號和構建日期，構建日期采用的是YYMMDD_HHMMSS這種標準格式，可以用Makefile或者IDE腳本自動獲取固件的編譯時間。
版本號貫穿嵌入式軟件開發的每一個環節，開發分支要對應明確的版本范圍，測試時要記錄清楚每一個測試用例對應的版本，量產時要把版本號和生產批次進行綁定。
上面介紹的四級版本號結構還可以進行靈活調整，可以簡化為三個級別的版本號結構，但核心要點還是要整個軟件流程保持一致，不能亂定義版本號的層級。
總的來說，嵌入式軟件需要有一套規范的版本號管理規則，然后再加上代碼的編程規范，這樣能讓嵌入式軟件迭代得更有條理，出現問題的時候也能快速進行回溯。
