为什么 angular 相关项目不使用 semver 2.0 作为预发布标签？

Question

许多 angular 相关项目使用以下预发布版本控制方案：

例如angular-cli

1.0.0-beta.22, 
1.0.0-beta.22-1,
1.0.0-beta.24

例如@angular/material

2.0.0-alpha.9
2.0.0-alpha.9-1,
2.0.0-alpha.9-2,
2.0.0-alpha.9-3,
2.0.0-alpha.10,
2.0.0-alpha.2.0.0-alpha.11, 
2.0.0-alpha.11-1,

由于语义版本控制的工作方式（点分隔符、数字始终低于字母数字部分的优先级），2.0.0-alpha.9-experimental-pizza 仍然是@angular/material 的最高版本，即使tough 2.0.0-alpha.11 已发布。

类似于 angular-cli，其中 1.0.0-beta.22-1 仍然是最高版本，即使 1.0.0-beta.24 已发布。

这会导致 package.json 与 ^ 版本的依赖关系，例如

"angular-cli" : "^1.0.0-beta.22-1"

不要升级到 1.0.0-beta.24，因为 24 是数字版本，因此小于 22-1。我也将此作为问题发布到@angular/material 问题跟踪器 here 但没有得到任何回复。

这只是一个疏忽，还是我遗漏了什么？

更新：

angular-cli 现在有版本

angular-cli@1.0.0-beta.25
angular-cli@1.0.0-beta.25.1
angular-cli@1.0.0-beta.25.2
angular-cli@1.0.0-beta.25.3
etc.

所以这似乎是一个疏忽。

Answer 1

简而言之，这些是手动流程。该团队尚未投资于自动化。至少这是针对 Angular CLI，因为我是存储库源代码的贡献者（但不是团队成员）。

在几乎所有最近的版本中，发布时发生了一些事情，所以他们不得不发布另一个版本。因此 1.0.0-beta.xx 之类的东西很快就被 1.0.0-beta.xx-1 紧随其后。

有些测试很难运行在发布包之前。特别是对于发布一系列包的 CLI，而不仅仅是一个（CLI 使用的几个 webpack 插件可以作为单独的包供其他非 CLI 种子项目使用）。

通常当团队对某个版本感到满意时，他们会明确地 tag 将其作为 latest，这是 npm 允许发布者做的事情，因此，理论上你不应该拥有这个 Angular Material alpha 9 vs alpha 11 问题，除非 alpha 11 没有被标记为最新或其他。

Answer 2

很久以后，我认为这是对 alpha / beta 的疏忽。此问题现已解决，angular 项目也遵循 semver 的预发布标签。

Why do angular releated projects do not use semver 2.0 for prerelease tags?