我正在维护some js library。发布遵循SemVer。当前的稳定版本为 1.5.0 。我正在研究 1.5.1 ，并且有 1.5.1-beta.2 ，该文件在npm上以“ next”标记发布。今天，我得到了错误报告，发现了问题并准备解决。问题是 1.5.1 不会在最近的几天内完成，结果比我最初计划的要复杂得多。但我希望发布此修补程序。
在这种情况下正确的策略是什么？我想避免的明显方法是将错误修复程序推迟到 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，您希望立即将其修复。正确的机制是派生1.5.0，修复错误集B，然后发布1.5.2（假设您不需要测试版）。然后将您的B修补程序合并到您的A工作分支中，并发布1.5.3-beta1并将其驱动到正式版本。
当您有两个并行的beta序列运行时，情况会变得有些复杂，尤其是当您不确定哪个会使其首先发布时，但它是可管理的。关键是要牢记，SemVer优先级如何影响客户做出的决策（他们应用的算法），是否将特定版本快速跟踪到他们的生产系统中，以及开发人员如何从您那里获取利益。 >
我的生产系统有两个输入：
当然，服务和包装产品也会有所不同。关键是，您可以使用发布点向客户自动化或开发人员发出信号，即您拥有一个重要的错误修复程序，几乎没有破坏任何东西的风险。不要求1.5.2的任何血统都可以追溯到1.5.1-beta＃。您不需要发布1.5.1。但是，通常在发行说明中添加注释，即1.5.2是1.5.0中的错误的热修复，并且不包含1.5.1-beta＃中的修复。
虽然您可能从未遇到过这样做的必要，但是您不必在最终的1.5.3版本中包括1.5.2中的错误修复程序，前提是更高的版本可以通过质量控制。有时是特定错误修复的情况，最终不适用于更高版本。
如何保持产品质量完全取决于您。 SemVer标准定义了如何表示特定版本的风险/重要性级别。