语义版本控制、先前版本的错误修复发布和树结构中的优先级

Question

我们使用semantic versioning。假设我们有一些版本号为 e.g. 的软件版本。 2.1.1。由于 API 更改，下一个版本的版本号为 3.0.0。现在让我们假设在版本2.1.1 和版本3.0.0 中都发现了一个错误。由于一些客户仍在使用2.1.1，我们不想强迫他们升级到3.0.1 或更高版本，我们为版本2.1.1 提供维护（错误修复）版本。此版本的直接版本号可能是2.1.2。虽然defintion of precedence 中没有给出这样的例子，但我会得出结论，这些规则暗示2.1.2 3.0.0 - 是什么意思？ 2.1.2 版是在 3.0.0 之后发布的，3.0.0 版不包括​​ 2.1.2 的所有错误修复。实际上这两个版本不是真正可订购的，版本（和相应的源修订）现在有一个树结构：

  |
2.1.1        (1)
  |\
  | \
  | 2.1.2    (3)
  |
3.0.0        (2)
  |

为了反映该树形结构并避免混淆，我更喜欢如下版本号方案：

  |
2.1.1        (1)
  |\
  | \
  | 2.1.1+m  (3)
  |
3.0.0        (2)
  |

（+m 用于维护版本）。根据语义版本控制中优先级的定义，这仍然意味着2.1.1+m 3.0.0，但对于我们的客户，我们可以添加一个规则，即x1.y1.z1 x2.y2.z2 任何版本x1.y1.z1+m* 都不能与@987654341 相提并论@（但 x1.y1.z1 x2.y2.z2+m* 仍然成立）。

是否有任何用于对树结构进行版本控制的最佳做法？还是我对语义版本控制有什么误解？

Answer 1

不，您不应该假设任何发布日期都按照 semver 优先关系排序，例如 2.1.2 < 3.0.0。您所能确定的是，它们之间可能已经发生了重大变化。

如果您想要构建日期信息，将其包含在构建元数据中是合理的，但该元数据与 semver 的优先级概念完全无关。然而，人类 可能会合理地得出结论，2.1.2+201706010005 版本可能是在3.0.0+201603151112 之后构建的。