许多角度相关项目使用以下的预发布版本控制方案：
e.g。角-CLI
1.0.0-beta.22,
1.0.0-beta.22-1,
1.0.0-beta.24
e.g。 @角/材料
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的最高版本，甚至很难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.
所以这似乎是一种疏忽。
答案 0 :(得分：0)
简短回答是这些是手动过程。该团队还没有投资自动化它们。至少那是为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没有被标记为最新或其他东西。
答案 1 :(得分：0)
很久以后，我认为这是对alpha / beta的疏忽。现在已经解决了这个问题，并且角度项目也会跟随semver用于预发布标记。