语义化版本控制规范(SemVer)

参考链接 https://semver.org/lang/zh-CN/

语义化版本 2.0.0

(透过版本号的改变来传达信息.)

摘要

版本格式: 主版本号.次版本号.修订号
版本号递增规则如下:
1.主版本号: 做了不兼容的API修改.
2.次版本号: 做了向下兼容的功能性新增.
3.修订号: 做了向下兼容的问题修正.

规范摘要:以下以x.y.z表示版本号格式

  • 上一级版本号递增时,下面的版本号必须归零.
  • 举个简单的例子就可以展示语义化的版本控制如何让依赖地狱成为过去。假设有个名为“救火车”的函式库,它需要另一个名为“梯子”并已经有使用语义化版本控制的包。当救火车创建时,梯子的版本号为 3.1.0。因为救火车使用了一些版本 3.1.0 所新增的功能, 你可以放心地指定依赖于梯子的版本号大等于 3.1.0 但小于 4.0.0。这样,当梯子版本 3.1.1 和 3.2.0 发布时,你可以将直接它们纳入你的包管理系统,因为它们能与原有依赖的软件兼容。
  • 0.y.z中 0 为主版本号,如 0.1.0 是初始化开发版本.并在后续的每次发行时递增次版本号.
  • 主版本为0时,表示仍在快速开发阶段,每天都在改变API.
  • 如果不小心把不兼容的改版当成了次版本号发行了该怎么办?
    • 一旦发现自己破坏了语义化版本控制的规范,就要修正这个问题.
    • 发行一个新的次版本号恢复向下兼容.
    • 不能修改已发行的版本.
    • 将有问题的版本号记录下来,告诉使用者问题所在,让他们知道这是一个有问题的版本.
  • 如何处理即将弃用的功能?
    • 更新文件说明让使用者知道这个改变.
    • 在适当时机将弃用的功能透过新的次版本号发布.
    • 在新的主版本完全移除弃用功能前,至少有一个次版本包含这个即将弃用的说明信息,这样使用者才能平顺地过渡到新版API中.

原文地址:https://www.cnblogs.com/sweetXiaoma/p/10349647.html

时间: 2024-11-09 04:52:49

语义化版本控制规范(SemVer)的相关文章

语义化版本控制的规范(转载)

最近在做app,版本编号有点乱,在网上看到这个版本控制规范,感觉很合理. 原文地址 :https://semver.org/lang/zh-CN/ 语义化版本 2.0.0 摘要 版本格式:主版本号.次版本号.修订号,版本号递增规则如下: 主版本号:当你做了不兼容的 API 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正. 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸. 简介 在软件管理的领域里存在着被称作"

版本号严格遵守semver语义化标准

地址:http://semver.org/lang/zh-CN/?spm=a219a.7629140.0.0.GUJMXE 语义化版本 2.0.0 摘要 版本格式:主版本号.次版本号.修订号,版本号递增规则如下: 主版本号:当你做了不兼容的 API 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正. 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸. 简介 在软件管理的领域里存在着被称作"依赖地狱"的

语义化版本2.0.0(版本规范)

转载 http://semver.org/lang/zh-CN/ 摘要 版本格式:主版本号.次版本号.修订号,版本号递增规则如下: 主版本号:当你做了不兼容的API 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正. 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸. 简介 在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一天发现自己已深陷绝望之中. 在依赖高的系统中发布新

语义化版本2.0.0

摘要 版本格式:主版本号.次版本号.修订号,版本号递增规则如下: 主版本号:当你做了不兼容的API 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正. 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸. 简介 在软件管理的领域里存在着被称作"依赖地狱"的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一天发现自己已深陷绝望之中. 在依赖高的系统中发布新版本套件可能很快会成为恶梦.如果依赖

semantic versioning语义化版本号

语义化版本号 是由github创始人 Tom Preston-Werner 发起的一个关于软件版本号的命名规范,关于这个规范详细的说明可以在 官网 查看,也可访问其 GitHub项目页面 ,官网文档: 语义化版本2.0.0 摘要 版本格式:主版本号.次版本号.修订号,版本号递增规则如下: 主版本号:当你做了不兼容的API 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正. 先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸. 简介

语义化版本

原文:http://semver.org/lang/zh-CN/ english [en] français [fr] pyccкий [ru] español [es] italiano [it] português brasileiro [pt-BR] 繁體中文 [zh-TW] 简体中文 [zh-CN] ??? [ko] slovensky[sk] ??????? [ar] 日本語 [jp] v2.0.0 语义化版本2.0.0 摘要 版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

语义化版本 2.0.0

http://semver.org/lang/zh-CN/ 语义化版本 2.0.0 摘要 版本格式:主版本号.次版本号.修订号,版本号递增规则如下: 主版本号:当你做了不兼容的 API 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正. 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸. 简介 在软件管理的领域里存在着被称作"依赖地狱"的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一

语义化版本编号

关于版本管理,学习了一下Tom Preston-Werner提出的语义化版本编号(SemVer).这里主要将其2.0.0的规范进行简单翻译,具体的其他细节可以参见其主页和github页面.我着这里仅作个人熟悉规则使用:

npm学习(八)之如何使用语义化版本

npm的语义化版本控制——Semantic versioning 在新发布的代码中传达更改的程度非常重要,因为有时更新会破坏包需要的代码(称为依赖项).语义化版本控制(semver)是一个旨在解决这个问题的标准. Semver出版商 如果一个项目要与其他项目共享,那么它应该从1.0.0开始(尽管npm上的一些项目不遵循这个规则). 在此之后,应按以下步骤处理更改: Semver消费者 在我们的package.json里面有一个version字段.那么,怎么在项目不断构建的过程中调整版本呢? np