摘要
版本格式:MAJOR.MINOR.PATCH
,版本号递增规则如下:
MAJOR
: 主版本号,当你做了不兼容的 API 修改MINOR
: 次版本号,当你做了向下兼容的功能性新增PATCH
: 修订号,当你做了向下兼容的问题修正先行版本号及版本编译信息可以加到 MAJOR.MINOR.PATCH
的后面,作为延伸。
基本的语法格式如下,更多请参考 Backus–Naur Form Grammar for Valid SemVer Versions
1 2 3 4 | <valid semver> ::= <version core> | <version core> "-" <pre-release> | <version core> "+" <build> | <version core> "-" <pre-release> "+" <build> |
---|
范例:
代码状态 | 等级 | 规则 | 版本样例 |
---|---|---|---|
首次发布 | 新品发布 | 以 1.0.0 开始 | 1.0.0 |
bug 修复,向后兼容 | 补丁版本发布 | 变更第三位数字 | 1.0.1 |
新功能,向后兼容 | 次版本发布 | 变更第二位数字,并且第三位数字重置为 0 | 1.1.0 |
重大变更,不想后兼容 | 主版本发布 | 变更第一位数字,并且第二位,第三位数字重置为 0 | 2.0.0 |
“v1.2.3” 是一个语义化版本号吗?
“v1.2.3” 并不是的一个语义化的版本号。
但是,在语义化版本号之前增加前缀 “v” 是用来表示版本号的常用做法。
在版本控制系统中,将 “version” 缩写为 “v” 是很常见的。
比如:git tag v1.2.3 -m "Release version 1.2.3"
中,标签是 “v1.2.3”,语义化版本号是 “1.2.3”。
以下关键词 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、OPTIONAL 依照 RFC 2119 的叙述解读。
语义化版本控制规范(SemVer)
例如:1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
Base
: 设计阶段,只有相应的设计没有具体的功能实现Alpha
: 软件的初级版本,基本功能已经实现,但存在较多的 bugBate
: 相对于 Alpha 已经有了很大的进步,消除了严重的 BUG,但还存在一些潜在的 BUG,还需要不断测试RC
: 该版本已经相当成熟了,基本上不存在导致错误的 Bug,与即将发行的正式版本相差无几RELEASE
: 最终发布版本,没有太大的问题最终发布版本(RELEASE
)之前的所有版本,都称为先行版本(pre-release
)。
通常我们发布一个包到 npm 仓库时,我们的做法是先修改 package.json 为某个版本,然后执行 npm publish 命令。手动修改版本号的做法建立在你对 Semver 规范特别熟悉的基础之上,否则可能会造成版本混乱。npm 考虑到了这点,它提供了相关的命令来让我们更好的遵从 Semver 规范:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # npm 发包 npm init # 1. 查看是否官方源 npm config get registry # 2. 登录 npm login # 3. 发布 npm publish # 版本变化 major.minor.patch npm version patch # 升级补丁版本 npm version minor # 升级小版号 npm version major # 升级大版号 # 下架 [-force] upm unpublish |
---|