语义版本控制，早期版本的bug-fix-releases和树结构中的优先级

Question

我们使用semantic versioning。假设我们有一些版本号为例如的软件版本。 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＆lt; 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＆lt; 3.0.0，但对于我们的客户，我们可以为x1.y1.z1＆lt; x2.y2.z2任何版本x1.y1.z1+m*都与x2.y2.z2不可比（但x1.y1.z1＆lt; x2.y2.z2+m*仍然有效。

是否有对树结构进行版本控制的最佳实践？或者我在语义版本控制方面遇到了什么问题？

Answer 1

不，您不应假设从2.1.2 < 3.0.0等semver优先级关系中排序任何发布日期。您可以确定的是，它们之间可能存在重大变化。

如果您想要构建日期信息，那么包含在构建元数据中是合理的，但该元数据与semver优先级概念完全无关。但是， human 可能会合理地断定版本2.1.2+201706010005可能是在3.0.0+201603151112之后构建的。