学习工程化怎么能对版本号不够清晰呢

一个版本号能有什么，确实没啥，但却很有用，我们都知道npm 的版本也就是package.json中的版本是可以使用node semver 用来进行版本操作的, 我们尝试的正式版，内测版等都有相关的规则的，也就是要语义化的，符合一定的规范的，接下来我们就逐步来了解一下神奇的verison 有哪些神奇之处呢？

版本号的结构

如下所示是基本的版本号格式，其-左侧是标准版本号 ，在 "标准版本号" 的基础上又增加了一个新的版本号区域：pre-release 区则是先行版本号,如下图所示：

标准版本格式

标准版本格式： 主版本号.次版本号.修订号 （即 major.minor.patch ），版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。

标准版本号必须采用X.Y.Z的形式，其中X, Y和Z是非负整数 ，并且不得包含前导零 。X表示主版本，Y表示次版本，Z表示补丁版本。每个元素必须以数字形式递增

大小比较 从左往右，按照数值的大小比较，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1

先行版本号

先行版本格式：

<标准格式>-<先行版本号>,在正式发布前，我们可能会有内测或是公测的一些情况，此时并不能保证这个版本的功能 100% 正常。这个时候就需要通过发布带上我们的先行版本号 ，例如1.0.0-alpha、1.0.0-alpha.1

下面列一下常用划分方式，按功能列了一下：

开发版:

Snapshot：快照，也被称为开发版，它不是个稳定版本，属于开发过程中使用的版本。类似npm link 方式，比如A 项目组开发后发布的新包，被 B 项目组引用，这时候使用快照版本snapshot，每次 A 项目组发布后，B 项目组都会刷新、重新编译的方式，自动更新到最新的 A 项目开发的依赖包。例如：1.0.0-SNAPSHOT.1

测试版本:

当一个项目开发完成后，就会进入测试版本，而测试版本一般会分为内部测试 alpha版、外部测试 beta版两种；alpha和beta区别就是beta版会向外公开，而alpha版不会。

Alpha (α)：内测版，内部交流或专业测试人员测试使用，例如:1.0.0-alpha.1
Beta (β)：公测版，专业爱好者大规模测试使用，存在一些 Bug，不适合一般用户使用，例如:1.0.0-beta。

扩展版:

α、β、λ 常用来表示软件测试过程中的三个阶段，rc是候选版本

Gamma (λ)：比较成熟的测试版。
RC (Release Candidate)：候选版本，处于 Gamma 阶段，该版本已经完成了全部功能并清除了大量的 Bug。到了这个阶段，只会修复 Bug，不会对软件做任何大的更改。一般来说，Alpha -> Beta -> Gamma 是迭代的关系，RC1 -> RC2 是取舍的关系。

大小比较

只有 数字标识符 比较时，则按数值的大小比较。
只有 非数字标识符 比较时，则按照 每个标识符 中 每个字符 在 ASCII 中的顺序来比较。
数字标识符 和 非数字标识符 比较时，则 非数字标识符 优先级高。
若每个标识符都相同的情况，则 标识符层级多 的先行版本号 优先级高。
混合比较，带有 先行版本号 的版本优先级 低于 相关联的 标准版本

大小关系如下：

matlab 复制代码

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

版本范围

我们在安装npm 包的时候，大家是不是会看到^1.2.1这个版本写法，更新 package.json 时，npm默认使用前缀 ^,当然也可以对其进行修改；

默认使用前缀~：npm config set save-prefix '~'
不使用前缀，保存确切版本：npm config set save-exact true 比如我们安装如下的包：

json 复制代码

  "dependencies": {
    "react": "~16.5.0",
    "react-dom": ">16.3.0 <16.6.0"
  },
  "devDependencies": {
    "vite": "4.3.0"
  }

执行命令如下：

kotlin 复制代码

npm i -S react-dom@">16.3.0 <16.6.0"
npm i -S react@~16.5.0  
//如果不添加 则会生成"vite": "^4.3.0"
npm config set save-exact true
npm i -D [email protected]

这就是npm 安装指定版本范围的方法，可以根据你的需求来定制去安装你想安装的版本，当然版本范围是一组满足指定范围的比较器，一个比较器是由操作符和版本号组成，我们先了解一下最原始的操作符：

<version: 小于某个版本
<=version: 小于或等于某个版本
>version: 大于某个版本
>=version: 大于或等于某个版本
=version: 等于某个版本；当没有操作符时，默认为等于=操作符，因此该操作符可以不用写。

当然除了基本的操作符外还有一些其它高级的表示语法，具体如下：

空也称锁定版本号

例如：1.0.0 只能匹配1.0.0

|| 表示或，则由双竖线||连接

例如：

1.2.3 || >=1.2.5 <2.0.0，将匹配 1.2.3、1.2.5和1.6.8等

X、x、* 在标准版本号中表示为一个数字的占位符表示的是一个自然数

例如：

* 相当于 >=0.0.0（任何版本都满足）
1.x 相当于 >=1.0.0 <2.0.0（匹配主版本号）
1.0.x 相当于 >=1.0.0 <1.1.0（匹配次版本号）

但有时我们也遇到 1 1.2 的版本号，这个其实相当于省略了，你可以把剩余的部分看成是* 或是空，比如1 相当于1.. ，1.2相当于1.2.*

^ 允许在不修改[major, minor, patch]中最左非零数字的更改，即 1.2.3 对2或3进行升级变动

例如：

1.2.3 相当于 >=1.2.3 <2.0.0
2.2.3 相当于 >=2.2.3 <3.0.0
0.2.3 相当于 >=0.2.3 <0.3
0.0.3 相当于 >=0.0.3 <0.0.4

~ 具有完整版本号结构的前提下，允许修订号级别的升级变动。

~1.2.3 相当于 >=1.2.3 <1.3.0
~1 相当于 >=1.0.0 <2.0.0
~0 相当于 >=0.0.0 <1.0.0
~0.2 相当于 >=0.2.0 <0.3.0
~1.2.3-beta.2 相当于 >=1.2.3-beta.2 <1.3.0-0

- 表示版本范围

例如：

1.2.3 - 2.3.4 相当于 >=1.2.3 <=2.3.4
1.2.3 - 2 相当于 >=1.2.3 <3.0.0

想了解具体信息可以看一下官方文档

也可以使用node semver 库来进行版本处理

复制代码

npm install semver

如果不确定，可以使用这个库比较看看，学会这些你就清楚如果npm 版本冲突了该如何解决，如果你想全部锁定版本该如何处理了吧，当然我们也可以通过npm view <packageName>查看具体的包信息，也可以npm view <packageName> versions 查看该包所有的版本,npm view <packageName> version 查看该包最新的版本号了，如下：

css 复制代码

npm view lucky-package-demo versions
[ '0.0.0', '0.0.1', '0.0.2', '0.0.3' ]