版本号的正确使用方式

产品

为项目的每个不同版本起的易于识别的标识号

1.版本号的命名容易犯下的错误

「每次只改最末位」

• 一直累加，无分类，从项目开始到结束 如1 到 +∞，看不出量变 如何产生 质变，无阶段性总结
• 上一个版本到下一个版本的api变化巨大。一个小版本中涵盖的内容过多，微小的版本升级却能引起整个项目的崩溃
• 依赖第三方组件时，无法标识每个版本依赖的组件，无法标识是否有所冲突

2.版本号的命名

国际主流惯例：
「语义化版本（Semantic Versioning）」，简称 SemVer

格式是：<major>.<minor>.<patch>
使用三位非负整数，以点号.连接。
e.g. 1.4.5、6.2.0

每个版本号的含义

major

主版本号，俗称大版本升级
标志着 API 发生了巨大变化，包括但不限于新增特性、修改机制、删除功能， 一般不兼容上一个主版本号。

minor-小版本升级

• 常规的新增或修改功能时，改动次版本号
• 必须是向前兼容，这也意味着我们不能直接删除某个功能。
• 如若必要，我们可以在修改日志中标记某项功能为「即将删除（Deprecated）」，然后在下一个大版本中将其彻底删除。

patch-补丁-bug修复

修订号，俗称 bug 修复。顾名思义，如果仅仅为了修复或调整一些小问题，我们就只改动修订号。

3. Notice

• 版本号前不要加v。
• 不要在数字前补0。错误示例：01.12.03。
• 每一位版本号按照+1的速度递增，不要在版本号之间跳跃。
• 主版本号停留在0的版本号，即0.x.x应当视作还在内部开发阶段的代码。如果代码有公共 API，此时不宜对外公开。
• 1.0.0的版本号用于界定公共 API 的形成。
• 如果不小心把一个不兼容的改版当成了次版本号发行，应当发行一个新的次版本号来更正这个问题并且恢复向下兼容。注意不能去修改已发行的版本。

refer：https://blog.csdn.net/qq_35246620/article/details/78443169