SemVer冲突：如果存在某些alpha / beta / rc版本并且工作正在进行中，如何在最新的稳定版本上发布错误修复？

Question

我保持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解决此类冲突？

Answer 1

[好，所以您有一个错误集A，目前正在以1.5.1-beta2的形式发布，并且您有一个新的错误集B，希望立即将其修复。正确的机制是派生1.5.0，修复错误集B，然后发布1.5.2（假设您不需要测试版）。然后将您的B修补程序合并到您的A工作分支中，并发布1.5.3-beta1并将其驱动到正式版本。

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

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

开发是我工程师的产品。
1. 自动维护是以下系统的产品：
2. 发布补丁并将其应用于我当前生产代码的fork。
3. 根据广泛的功能和性能测试套件来测试应用的更改。
4. 如果测试是绿色的，飞行测试我的生产环境中的变化，同时监视生产失败率的异常变化。
5. [只要一切顺利，并且人们没有介入阻止它，最终将更改发布到整个生产系统。

当然，服务和包装产品也会有所不同。关键是，您可以使用发布点向客户自动化或开发人员发出信号，即您拥有一个重要的错误修复程序，几乎没有破坏任何东西的风险。不要求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标准定义了如何表示特定版本的风险/重要性级别。