SemVer 冲突:如果有一些 alpha/beta/rc 版本并且工作正在进行中，如何在上一个稳定版本上发布错误修复? [英] SemVer collision: How to release bug fix over the last stable version if there are some alpha/beta/rc versions and the work is in progress?

问题描述

我正在维护一些js库.发布遵循 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，您想要修复它立即地.正确的机制是 fork 1.5.0，修复错误集 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 标准定义了您如何表示特定版本的风险/重要性级别.

I'm maintaining some js library. Releases follow SemVer. Current stable version is 1.5.0. I'm working on 1.5.1 and have 1.5.1-beta.2 which is published at npm with "next" tag. Today I got bug report, discovered the issue and ready to fix it. The thing is that 1.5.1 is not going to be finished during nearest days, it turned out to be more complicated than I planned initially. But I want the fix to be published.

What is the right strategy in this situation? Obvious approach which I'd like to avoid is to postpone the bug fix until 1.5.1 is done and published and then release 1.5.2 containing the fix.

Another way is to publish the fix as 1.5.1 based on 1.5.0 and then continue previous work switching it from 1.5.1-beta.2 to 1.5.2 or even 1.6.0. I'm concerning about inconsistency with the result chain in this case:

1.5.0 → 1.5.1-beta → 1.5.1-beta.1 → 1.5.1-beta.2 → 1.5.1 (bug fix, based on 1.5.0) → 1.5.2 (based on 1.5.1-beta.2)

How such collisions are being addressed using SemVer?

解决方案

Okay, so you have bug set A currently baking as 1.5.1-beta2 and you have a new bug set B that you want to get the fix out for immediately. The correct mechanism for this is to fork 1.5.0, fix bug set B, and release 1.5.2 (assuming you don't need a beta). Then merge your B fixes into your A working branch and release 1.5.3-beta1 and proceed to drive that to an official release.

It gets a little more complicated when you have two parallel beta sequences running, particularly when you're not sure which is going to make it to release first, but it is manageable. The key is to to just keep in mind, how SemVer precedence impacts the decisions your customers make (the algorithms they apply), whether to fast-track a particular version into their production systems, verses how their developers pull bits from you.

My production systems, have two inputs:

1. Development is the product of my engineers.
2. Automated maintenance is the product of a system that:
   • Pulls patch releases and applies them to a fork of my current production code.
   • Tests the applied changes against an extensive suite of functional and performance tests.
   • If the tests are green, flight tests the changes in my production environment, while monitoring for unusual changes in production failure rates.
   • As long as everything is going well and a human doesn't step-in to stop it, eventually rolls out the changes to the entire production system.

There are of course, variations for services and packaged products. The point is, you can use your release points to signal to your customers automation, or developers, that you have an important bug fix that has little risk of breaking anything. There is no requirement that 1.5.2 have any lineage back to 1.5.1-beta#. You are not required to ever release a 1.5.1. It is customary however to add a comment in your release notes that 1.5.2 is a hot fix for the bug in 1.5.0 and does not contain the fixes in 1.5.1-beta#.

While you may never encounter a need to do so, you don't have to include the bug fixes from 1.5.2 in your eventual 1.5.3 release, provided the later release, passes your quality controls. It is sometimes the case that a specific bug fix, winds up not being applicable in later releases.

How you maintain your product quality is entirely up to you. How you signal the level of risk/importance for a specific release, is defined by the SemVer standard.

这篇关于SemVer 冲突:如果有一些 alpha/beta/rc 版本并且工作正在进行中，如何在上一个稳定版本上发布错误修复?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！