npm - SemVer 冲突 : How to release bug fix over the last stable version if there are some alpha/beta/rc versions and the work is in progress?

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.1 基于 1.5.0 然后继续之前的工作，从 切换它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-测试版.2)

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

Answer 1

好的，所以您的错误集 A 当前正在烘焙为 1.5.1-beta2，并且您有一个新的错误集 B，您想立即修复它。正确的机制是 fork 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 定义。标准。