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.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 (bug修复，基于1.5.0) → 1.5.2 (基于1.5 .1-beta.2)

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

Answer 1

好的，您有一个错误集 A 当前正在烘焙为 1.5.1-beta2，并且您有一个新的错误集 B，您希望立即修复该错误集。正确的机制是 fork 1.5.0，修复 bug 集 B，然后发布 1.5.2(假设您不需要测试版)。然后将您的 B 修复合并到 A 工作分支并发布 1.5.3-beta1 并继续将其驱动为正式版本。

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

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

1. 开发是我的工程师的成果。
2. 自动维护是以下系统的产物:
   • 提取补丁版本并将其应用到我当前生产代码的分支。
   • 根据一系列广泛的功能和性能测试来测试所应用的更改。
   • 如果测试通过，则会对生产环境中的变化进行飞行测试，同时监控生产故障率的异常变化。
   • 只要一切进展顺利，并且无人介入阻止，最终会将更改推广到整个生产系统。

当然，服务和包装产品也有变化。关键是，您可以使用发布点向客户自动化或开发人员发出信号，表明您已经修复了重要的错误，并且几乎没有破坏任何内容的风险。不要求 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 定义。标准。