版本号命名规则

版本号的格式为 X.Y.Z(又称 Major.Minor.Patch),递增的规则为:

  • X 表示主版本号,当 API 的兼容性变化时,X 需递增。
  • Y 表示次版本号,当增加功能时(不影响 API 的兼容性),Y 需递增。
  • Z 表示修订号,当做 Bug 修复时(不影响 API 的兼容性),Z 需递增。

详细的规则如下:

  • X, Y, Z 必须为非负整数,且不得包含前导零,必须按数值递增,如 1.9.0 -> 1.10.0 -> 1.11.0
  • 0.Y.Z 的版本号表明软件处于初始开发阶段,意味着 API 可能不稳定;1.0.0 表明版本已有稳定的 API。
  • 当 API 的兼容性变化时,X 必须递增,Y 和 Z 同时设置为 0;当新增功能(不影响 API 的兼容性)或者 API 被标记为 Deprecated 时,Y 必须递增,同时 Z 设置为 0;当进行 bug fix 时,Z 必须递增。
  • 先行版本号(Pre-release)意味该版本不稳定,可能存在兼容性问题,其格式为:X.Y.Z.[a-c][正整数],如 1.0.0.a1,1.0.0.b99,1.0.0.c1000。
  • 开发版本号常用于 CI-CD,格式为 X.Y.Z.dev[正整数],如 1.0.1.dev4。
  • 版本号的排序规则为依次比较主版本号、次版本号和修订号的数值,如 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0;对于先行版本号和开发版本号,有:1.0.0.a100 < 1.0.0,2.1.0.dev3 < 2.1.0;当存在字母时,以 ASCII 的排序来比较,如 1.0.0.a1 < 1.0.0.b1。
  • 注意:版本一经发布,不得修改其内容,任何修改必须在新版本发布!

一些修饰的词

  • alpha:内部版本
  • beta:测试版
  • demo:演示版
  • enhance:增强版
  • free:自由版
  • full version:完整版,即正式版
  • lts:长期维护版本
  • release:发行版
  • rc:即将作为正式版发布
  • standard:标准版
  • ultimate:旗舰版
  • upgrade:升级版
### 关于嵌入式系统的版本号命名规范 在开发和管理嵌入式系统的过程中,采用一致且清晰的版本号命名规范有助于团队成员之间的沟通以及产品的有效管理和追踪。虽然特定行业或公司可能有不同的标准实践,但普遍接受的一些原则可以指导这一过程。 #### 通用建议 - **语义化版本控制**:遵循`MAJOR.MINOR.PATCH`模式是一种常见的做法。每当引入不兼容API更改时增加主要版本号;当向后兼容的功能被添加到公共API中时提升次要版本号;而修复错误则通过补丁版本号体现[^1]。 - **预发布标签**:可以在上述基本结构后面附加额外的信息来表示特殊状态(如alpha、beta测试阶段),例如 `v1.0.0-alpha+build.1`. - **构建元数据**:有时还会加入描述具体编译环境或其他细节的数据作为补充说明部分, 如 `-rc.1`, 这样可以帮助更精确地区分不同构建间的差异. #### 实际案例展示 假设有一个用于汽车电子控制单元(ECU) 的固件更新计划: ```plaintext Firmware Version: v2.3.4-beta+git.sha.abcd1234 ``` 这里解释如下: - 主要版本 (`2`) 表明这是第二次重大的架构变更. - 次要版本 (`3`) 显示自上次大改以来增加了三个新特性集. - 补丁级别 (`4`) 则记录了针对已知问题所做的四次修正. - 预发行标记(`beta`) 提醒用户当前处于公开试用期. - 构建信息(`git.sha.abcd1234`) 可能指向具体的源码提交哈希值以便追溯. 这种详细的版本控制系统不仅便于内部跟踪进度也方便外部客户理解产品演化路径.
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值