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

npm的语义化版本控制——Semantic versioning

在新发布的代码中传达更改的程度非常重要,因为有时更新会破坏包需要的代码(称为依赖项)。语义化版本控制(semver)是一个旨在解决这个问题的标准。

Semver出版商

如果一个项目要与其他项目共享,那么它应该从1.0.0开始(尽管npm上的一些项目不遵循这个规则)。

在此之后,应按以下步骤处理更改:

Semver消费者

在我们的package.json里面有一个version字段。那么,怎么在项目不断构建的过程中调整版本呢?

npm有一套自己的版本控制标准——Semantic versioning(语义化版本)

具体体现为:对于"version":"x.y.z"

  • 修复bug,小改动,增加z
  • 增加了新特性,但仍能向后兼容,增加y
  • 有很大的改动,无法向后兼容,增加x

例如:我原本的项目是1.0.0版本的话

  • 若是1中情况,变为1.0.1
  • 若是2中情况,变为1.1.0
  • 若是3中情况,变为2.0.0

通过命令npm version <update_type>自动改变版本

update_type为patch, minor, or major其中之一,分别表示补丁,小改,大改

例如我在shell去改动项目版本

此命令将更改package.json中的版本号。再来看看我的package.json,已经变成了v1.0.0

更新版本号之后,再次运行npm publish。

原文地址:https://www.cnblogs.com/kunmomo/p/11221866.html

时间: 2024-10-12 12:56:20

npm学习(八)之如何使用语义化版本的相关文章

语义化版本编号

关于版本管理,学习了一下Tom Preston-Werner提出的语义化版本编号(SemVer).这里主要将其2.0.0的规范进行简单翻译,具体的其他细节可以参见其主页和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 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正. 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸. 简介 在软件管理的领域里存在着被称作"依赖地狱"的死亡之谷,系统规模越大,加入的套件越多,你就越有可能在未来的某一

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

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

semantic versioning语义化版本号

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

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

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

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

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

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

参考链接 https://semver.org/lang/zh-CN/ 语义化版本 2.0.0 (透过版本号的改变来传达信息.) 摘要 版本格式: 主版本号.次版本号.修订号 版本号递增规则如下: 1.主版本号: 做了不兼容的API修改. 2.次版本号: 做了向下兼容的功能性新增. 3.修订号: 做了向下兼容的问题修正. 规范摘要:以下以x.y.z表示版本号格式 上一级版本号递增时,下面的版本号必须归零. 举个简单的例子就可以展示语义化的版本控制如何让依赖地狱成为过去.假设有个名为"救火车&qu