先决条件什么是版本？语义版本控制（Semanticversion以下简称SemVer）是近几年不断发展的版本控制系统。随着每天都在构建新的插件、插件、扩展和库，有一个通用的软件开发项目版本控制方法是很好的，它可以帮助我们跟踪正在发生的事情。SemVer的格式是x.y.z，其中：x代表主要版本（Major）y代表次要版本（Minor）z代表补丁（Patch）SemVer是如何工作的？使用SemVer来确定您应该发布哪种类型的版本很简单。如果你修复了一个错误或修改了一些细节，那么这将被归类为一个补丁，在这种情况下你应该升级z。如果您以向后兼容的方式实现新功能，那么您将升级y，因为这就是所谓的次要版本。另一方面，如果你实现了一些可能破坏现有API的新东西，你需要升级x，因为它是一个主要版本（Major）。更多信息，请参见下文<更多注意事项>。语义版本控制对于应用程序非常重要。当然，版本升级就成了一件看似不重要但非常重要的事情。在我们开发的过程中，或者您遇到过这样的情况吗？因为版本控制的概念模糊或者被遗忘，构建的应用程序的版本被随便更改或者版本被完全遗忘。每次构建完都要改版本太麻烦，我也懒得改了。基于这个场景，我开发了这个自动版本升级管理工具auto-versgithub：https://github.com/zerolty/au...同库对比项目npm-auto-versionupdate-versionauto-versgittag不支持支持自动更新不支持支持提示更新不支持不支持支持手动和auto-vers对比下面是我们需要手动改的（前提要知道改什么，不能忘记修改！）下面是使用auto-vers的方法。特性[x]更新major,minor,patch,premajor,preminor,prepatchorprerelease[x]更新时提示选择[x]支持gittag方式[]根据gitcommit信息自动推荐合适的版本使用Node和Cli两种导入方法。npmiauto-vers-gCLI基本模式catpackage.json{..."version":"1.0.0"...}auto-vers-icatpackage.json{..."version":"1.0.1"...}确认模式auto-vers-i-c提示模式auto-vers-t如果不想更新可以用ctrl+c停止。Prompt和Git组合模式使用这个选项后，当你选择一个版本后，它会自动为你提交一个commit并用标签标记。auto-vers-t-g直接更改模式auto-vers1.2.0或auto-vers-v1.2.0选项auto-vers1.0.2为您的应用程序自动更新版本用法：auto-vers[options][[...]]Options-v--version可以直接更新版本。-i--inc--increment[]将版本增加指定级别。级别可以是以下之一：major、minor、patch、premajor、preminor、prepatch或prerelease。默认级别是“补丁”。只能指定一个版本。-e--extra[]这是prereleaseextradata比如'beta','alpha'-c--confirm不要直接更新版本，可以confirm。这是一种安全模式。-t--tip为您提供选择。如果您不知道如何更新，您可以选择此选项。-g--git帮你打标签。（让你有一个gitrepo）最佳实践当你打包你的项目时运行这个命令是一个很好的选择。基本方式"script":{"build":"babel./src--out-dir./dist","tip":"npmrunbuild&&auto-vers-t","version":"npmrunbuild&&auto-vers-t-g",}写完打包命令后，后面跟着auto-vers-t，会提示你需要升级到多少个版本，这对你有一定的指示意义。帮助您更好地判断需要升级到哪个版本。auto-vers-t-g这个命令适合你单独发布一个版本，它可以帮助你修改整个流程package.json->gitcommit->gittag->gitpushorigin[tagname]一个点击。中间方式"script":{"build":"babel./src--out-dir./dist","patch":"npmrunbuild&&auto-vers-i-c","minor":"npm运行build&&auto-vers-iminor-c","major":"npmrunbuild&&auto-vers-imajor-c","beta":"npmrunbuild&&auto-vers-iprerelease-c",}这个方法针对的是熟悉这个模式的人。每次需要打包时，只需要执行相应的命令即可。（添加参数-c--confirm，这是一种安全的升级方式，帮助你确认升级是否正确，如果这对你来说是一个繁琐的步骤，你可以去掉它。)高级方式git-hooks如果你还没有注册pre-commit和post-commit，你可以直接移动到你的.hook下，手动添加到你的hookcatgithook-*/pre-commit>>.git/hooks/pre-commit提交commit时，会自动弹出选择界面，选择后升级对应版本.（注意：如果你的程序中有commit命令，请使用--no-verify跳过这个钩子，否则会循环调用）更多关于为什么选择SemVer的信息，因为非标准版本号基本都有没意思。从4.1.0升级到4.2？好的，为什么？为什么不是5？为什么不是4.1.1？为什么不是4.11？为什么不是4.1.0-aplha.0？严格的准则有助于为版本号提供意义。例如，如果你看到版本1.3.37，那么你就会知道这是第一个主要版本，但是已经有3个次要版本带来了新功能。但是，您还会注意到这是此次要版本中的第37个补丁，这意味着涉及很多错误（或大或小）。也有助于管理依赖，"babel-cli":"~6.26.0"，我们引入了babel-cli，可以知道他的版本是6.26.0，他会锁住x,y这是一种在a比较保守的方式，根据规则，可以知道z的升级不会导致我们的API有大的变化，也不会引入新的功能。但是，如果babel-cli不遵循SemVer，则在升级z时会引入重大更改，这将使我们的应用程序出现错误或无法使用。正是因为有了SemVer的规范，我们才能安全的锁定x，y，让z能够自动升级，因为z的升级可能会修复一些小bug或者改进一些细节，可以在不破坏我们应用的情况下使用。已知错误已修复。更多小贴士既然你知道了SemVer是什么以及如何自动更新它，那么让我们谈谈更新时要注意的一些事项。从0.1.0开始使用SemVer时需要注意的一件事是它以0.1.0开头，而不是我们想象的0.0.1。这是有道理的，因为我们不是从补丁开始，而是从一组功能开始，作为项目的初稿，因此是版本0.1.0。在1.0.0之前，它只是一个开发阶段每当您构建一个新软件时，总会有一个困惑的阶段，您会不断问自己：我应该什么时候发布第一个官方主要版本？这里有一些提示可以帮助您回答这个问题：如果您的应用程序已经投入生产或用户依赖它，那么您应该已经达到1.0.0。另外，如果你破坏了当前的API，这也意味着你需要升级你的主要版本号。否则，请记住，低于1.0.0的版本基本上是开发繁荣时期，您可以专注于完成您的功能。在1.0.0之前，您不应该害怕任何破坏性功能，因此到1.0.0时，它会很稳定。关于pre-releasepre-release在部署主要版本之前，您通常会进行大量需要反复测试的工作，以确保一切正常。使用SemVer，可以通过将标识符附加到版本来定义预发布。例如，版本1.0.0的预发布可能是1.0.0-alpha.1。然后，如果需要另一个预发布版本，它将变为1.0.0-alpha.2，依此类推。总结通过上述基础知识后，如果您不使用SemVer，则没有理由不在您的下一个项目（或当前项目？）中使用它。它不仅可以帮助您的项目版本变得有意义，而且还可以帮助其他可能将您的项目用作依赖项的人。说了这么多，最后还是希望大家能够更加规范的开发项目，既能帮助别人，也能造福自己。可能我开发的项目没有那么完美，但初衷是为了提高大家规范的效率。如有BUG请多指出，如有功能性问题请坦诚。友情链接青秋风无影er参考https://medium.com/fiverr-eng...https://www.sitepoint.com/sem...
