固件版本管理基础
版本管理这事儿，看着简单，做起来全是坑。我见过太多团队，前期版本号随便写，到了要回滚的时候才发现——根本分不清哪个版本该滚到哪去。说白了，版本管理就是给固件打上「身份证」，让系统知道你是谁、从哪来、能不能退回去。
这一章，咱们就把版本管理的四个基本功掰开揉碎讲清楚。
版本号编码规范
版本号不是随便写的数字。我习惯用三段式：主版本.次版本.修订号。举个例子，2.1.3 表示主版本 2、次版本 1、第 3 次修订。
三段式编码规则
- 主版本：架构变更、协议不兼容、存储布局重做时递增。比如从 v1 升到 v2，意味着旧固件不能直接升级到新固件，得走中间版本过渡。
- 次版本：新增功能、接口扩展，但向后兼容。比如 v2.1 到 v2.2，升级后还能回滚到 v2.1。
- 修订号：Bug 修复、安全补丁、性能优化。v2.1.3 到 v2.1.4，改动最小，回滚风险也最低。
我在项目中遇到过一种情况：某团队把版本号写成 20250301，看着像日期，结果同一天发布了两个紧急补丁，版本号直接撞车。你想想看，回滚时系统该选哪个？
所以，我建议再加一个构建号，比如 2.1.3.45，最后一位是 CI 流水线自动生成的递增编号。这样每个固件都是唯一的，不会重复。
我的习惯：版本号里不要带字母，除非是预发布标记（alpha、beta、rc）。正式发布的固件，只用数字和点号。为什么？因为有些 bootloader 解析版本号时，遇到字母就崩了。
版本存储结构
版本号存哪儿？怎么存？这直接决定了回滚能不能跑起来。
我一般把版本信息放在固件头的固定偏移处。结构体大概长这样：
typedef struct {
uint32_t magic; // 魔数，0xDEADBEEF，用于校验固件完整性
uint32_t version_major; // 主版本号
uint32_t version_minor; // 次版本号
uint32_t version_patch; // 修订号
uint32_t version_build; // 构建号
uint32_t timestamp; // 编译时间戳
uint32_t crc32; // 固件体 CRC32 校验值
uint32_t reserved[8]; // 保留字段，给未来扩展用
} firmware_header_t;这里有个细节：魔数和CRC32必须放在头部前 8 字节内。为什么？因为 bootloader 启动时，先读前 8 字节判断固件是否有效，有效才继续加载。我曾经见过一个产品，魔数放在尾部，结果 bootloader 每次都要扫描整个 Flash 才能找到版本信息——启动慢了 3 秒，客户直接投诉。
版本存储的位置，我推荐两种方案：
| 方案 | 存储位置 | 优点 | 缺点 |
|---|---|---|---|
| 方案 A | 固件头部（Flash 起始地址） | 读取快，bootloader 直接访问 | 固件升级时头部会被覆盖 |
| 方案 B | 独立版本分区（如 OTP 或 EEPROM） | 版本信息持久化，不受固件升级影响 | 需要额外存储空间，增加成本 |
我个人偏向方案 A + 备份：主版本信息在固件头部，同时在 Flash 末尾保留一个备份区域，存一份版本号的副本。这样即使固件升级写坏了头部，还能从备份区读到版本信息。
注意：版本存储结构一旦定下来，就不要轻易改。我见过一个团队，产品发布后改了版本结构体的大小，结果旧固件升级到新固件时，bootloader 解析头部直接越界——整批设备变砖。改结构体，必须考虑向前兼容。
版本生命周期管理
每个版本都有它的「生老病死」。我习惯把版本分成四个阶段：
- 开发版：内部测试用，版本号带
-dev后缀。这个阶段的固件不能进入生产环境，也不能作为回滚目标。 - 候选版：RC 版本，功能冻结，只修 Bug。版本号如
2.1.0-rc1。可以小范围灰度，但回滚策略要谨慎。 - 正式版：发布给客户，版本号干净。这个版本必须支持回滚到上一个正式版。
- 废弃版：发现严重漏洞或兼容性问题，标记为废弃。系统在回滚时跳过废弃版本。
为什么要废弃版本？我举个例子。某次我们发布了一个正式版，结果发现新版本改了 Flash 驱动，导致旧版本无法直接升级。我们立刻标记这个版本为废弃，并强制所有设备升级到下一个修复版本。如果没有废弃机制，用户可能手动回滚到那个有问题的版本——那就炸了。
生命周期管理的关键规则
- 只有正式版可以作为回滚目标
- 废弃版必须从回滚列表中移除
- 开发版和候选版不能进入生产环境
- 每个版本必须记录发布时间和状态变更时间
版本兼容性策略
兼容性策略，说白了就是回答一个问题：这个版本能不能回滚到那个版本？
我把它分成三个层级：
| 兼容性层级 | 定义 | 回滚策略 |
|---|---|---|
| 完全兼容 | 版本之间存储结构、通信协议、配置参数完全一致 | 允许任意回滚 |
| 向前兼容 | 新版本能处理旧版本的数据，但旧版本不认识新版本的数据 | 只能回滚到相邻版本，不能跨版本回滚 |
| 不兼容 | 存储布局或协议发生重大变更 | 禁止回滚，必须走迁移流程 |
这里有个实战经验：永远假设你的固件会回滚。我在设计存储结构时，会在每个关键数据结构前面加一个 version_tag 字段。这样，当新版本写入数据时，旧版本读到这个 tag，就知道「这数据我不认识」，然后走默认值或降级逻辑。
typedef struct {
uint32_t tag; // 数据版本标记，如 0x00010002
uint32_t length; // 数据长度
uint8_t data[]; // 实际数据
} config_item_t;举个例子。v2.0 的配置项有 3 个字段，v2.1 新增了第 4 个字段。如果设备从 v2.1 回滚到 v2.0，v2.0 读到 tag 是 2.1 的版本，就知道第 4 个字段它不认识——直接忽略，用默认值填充。这样回滚就不会崩。
避坑指南：我曾经在某个项目里，新版本把配置项的枚举值从 0-2 扩展到了 0-5。回滚到旧版本后，旧版本读到枚举值 3，直接 switch-case 走到 default 分支——设备死机。从那以后，我规定：枚举值只能追加，不能修改已有值的含义。如果非要改，就新增一个字段，废弃旧字段。
最后，我画了一张图，把版本管理的核心逻辑串起来：
嗯，版本管理的基础就这些。你想想看，如果版本号乱写、存储结构随意、生命周期不清晰、兼容性策略靠猜——那回滚保护就是空中楼阁。下一层，咱们会深入回滚的具体实现机制，但前提是，你得先把这四块地基打牢。