我正在阅读有关使用npm.
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease]
预发行
假设您的包从版本开始0.0.0
npm version prerelease=>0.0.1-0
npm version prerelease=>0.0.1-1
基本上只是在破折号后增加数字
预补丁
从0.0.0使用 pre[major|minor|patch] 开始...
npm version prepatch=>0.0.1-0
npm version preminor=>0.1.0-0
npm version premajor=>1.0.0-0
修补
从0.0.0使用补丁开始...
npm version patch=>0.0.1
npm version patch=>0.0.2
我了解碰撞主要次要版本和补丁版本的规则，但是之前版本控制的标准约定是什么1.0.0？
我还没有看到使用 pre-1.0.0 的 prelease 版本。这似乎毫无意义，因为公共 API 尚未最终确定。它们在 1.0.0 发布后变得有用。
来自semver.org：
1.0.0 版定义了公共 API。此版本后版本号的递增方式取决于此公共 API 及其更改方式。
和：
预发布版本可以通过在补丁版本之后附加一个连字符和一系列点分隔标识符来表示。...预发布版本表明该版本不稳定，可能无法满足其相关正常版本所表示的预期兼容性要求。
我在 1.0.0 之前看到的约定包括使用补丁来修复错误/拼写错误，以及使用次要版本来进行任何重大修改。1.0.0 之前的约定没有那么严格，因为还没有保证公共 API。
当您想与社区分享一些早期功能时，预发布版本会派上用场。
例如，在撰写本文时，npm-check-updates的最新稳定版本是 version 1.5.1。我添加的一些新功能引入了向后不兼容的更改，因此为了符合 semver，我必须在2.0.0. 2.0.0然而，在社区进行更彻底的测试之前，我不想作为最新的稳定版本发布。因此，我发布了一个预发布版本（使用npm publish --tag unstable），版本为2.0.0-alpha.1. 社区成员可以安装预发布版本（带有npm install -g npm-check-updates@unstable）以试用最新功能，而普通用户npm install -g npm-check-updates将继续1.5.1为大多数用户安装稳定版本。当预发布版本证明自己时，我可以轻松地将其发布为2.0.0.