Npm SemVer冲突：如果有一些alpha/beta/rc版本，并且工作正在进行中，如何在上一个稳定版本上发布bug修复？

我在维护。在SemVer之后发布。当前的稳定版本是1.5.0。我正在研究1.5.1，并拥有1.5.1-beta.2，在npm上发布，带有“下一个”标签。今天我收到错误报告，发现了问题并准备修复它。问题是，1.5.1不会在最近几天内完成，结果比我最初计划的要复杂。但我想公布修正案

在这种情况下，正确的策略是什么？我想避免的明显方法是将bug修复推迟到1.5.1完成并发布，然后发布包含修复的1.5.2

另一种方法是基于1.5.0将补丁发布为1.5.1，然后继续之前的工作，将其从1.5.1-beta.2切换到1.5.2甚至1.6.0。我担心在这种情况下与结果链不一致：

1.5.0→ 1.5.1-beta→ 1.5.1-beta.1→ 1.5.1-beta.2→ 1.5.1（错误修复，基于1.5.0）→ 1.5.2（基于1.5.1-beta.2）

---

如何使用SemVer解决此类冲突？

好的，因此您将错误集A当前设置为1.5.1-beta2，并且有一个新的错误集B，您希望立即获得修复。正确的机制是fork 1.5.0、修复bug集B和发布1.5.2（假设您不需要beta版）。然后将B修复程序合并到A工作分支和1.5.3-beta1版本中，并继续将其驱动到正式版本

当你有两个并行的测试序列运行时，它会变得更复杂一些，特别是当你不确定哪一个会让它首先发布时，但是它是可以管理的。关键是要记住，SemVer优先级如何影响客户的决策（他们应用的算法），是否将特定版本快速跟踪到他们的生产系统中，以及他们的开发人员如何从您那里获取信息

我的生产系统有两个输入：

开发是我的工程师的产品

自动化维护是系统的产品，该系统：

• 提取补丁版本并将其应用于我当前生产代码的分支
• 根据一系列广泛的功能和性能测试测试应用的更改
• 如果测试为绿色，则飞行测试生产环境中的变化，同时监控生产故障率的异常变化
• 只要一切进展顺利，人类不介入阻止它，最终将对整个生产系统进行更改

---

当然，服务和包装产品也有变化。关键是，您可以使用您的发布点向您的客户或开发人员发出信号，表明您有一个重要的bug修复，几乎没有破坏任何东西的风险。不要求1.5.2有任何追溯到1.5.1-beta的血统。您不需要发布1.5.1。但是，通常在发行说明中添加一条评论，指出1.5.2是1.5.0中bug的热修复程序，不包含1.5.1-beta中的修复程序

虽然您可能永远不会遇到这样做的需要，但您不必在最终的1.5.3版本中包含1.5.2中的错误修复，只要以后的版本通过了质量控制。有时，一个特定的bug修复程序最终不适用于以后的版本

---

如何保持产品质量完全取决于您。标准定义了您如何表示特定版本的风险/重要性级别。

“您不需要发布1.5.1”