什么是语义化版本号?
- 语义化版本号,这个词说明首先是一个版本号,再者才是语义化的版本号。
- 说起版本号,我们日常应该有看到,例如微信的每次更新都有版本号,像下图就是从微信官网截图来的。
- 版本号是用来区分每次发布的版本的。这样方便软件开发人员迭代优化。而本篇文章所说的语义化版本号,是在版本号基础上添加语义信息。
- 换句话说,语义化版本号就是让版本号可以表达语义信息,看到本次发版的版本号,就能知道这个版本做了什么。
语义化版本2.0.0
- 语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 所建立。
- 当我们发版新的包时,语义化版本号规则:
- 版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
- 主版本号:当你做了不兼容的 API 修改,
- 次版本号:当你做了向下兼容的功能性新增,
- 修订号:当你做了向下兼容的问题修正。
- 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
- 版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
- 建立这套规范的契机,大家也可以移步到这里查看,总结来说就是,当一个系统越大越庞大,加入的包越来越多时,避免陷入“依赖地狱”的死亡之谷。
- 因为官网已经介绍的很清楚了,我这里只是作抛砖引玉,大家可以去这里获取第一手资料。
这个有哪些作用呢?
- 针对发包的人员。可以根据每次发包前做的改动,来确定是更改语义化版本号的哪个部分。例如
rapidocr_onnxruntime
包,当前版本是v1.2.3
:- 当我做了向下兼容的问题修正,应该只增加最后一位,版本号变为
v1.2.4
- 当我为这个包增加了向下兼容的功能模块,那应该增加中间位置,末位清零,版本号变为
v1.3.0
- 当我更新了包的API接口,并不能向下兼容,应该增加第一位数字,其他位置清零,版本号变为
v2.0.0
- 当我做了向下兼容的问题修正,应该只增加最后一位,版本号变为
- 针对使用包的人员。我们使用一个包时,可以先看它的版本号,如果遵守语义化版本号,我们可以限定使用包的版本范围,来避免不兼容的问题发生。
- 例如:之前看到一个包依赖
distlib
库,写的就是dislib<1,>=0.3.6
。这就说明只依赖distlib
这个库1.0版本以下,大于等于0.3.6的版本。从字面意思上来看,这就是避免1.0以上版本可能会出现不详细兼容的问题。
- 例如:之前看到一个包依赖
写在最后
- 目前经我手发的包,版本号均已经遵从语义化版本规范。详情可以参见RapidOCR中所有的pypi的包。
- 有了这个规范,冷冰冰的版本号不再毫无意义,而是变得有意思起来。