为什么视图从3.8跳到3.10 (3.9发生了什么事)？

Question

昨天有一个发布安全咨询意见，但新版本比上一个版本(3.10到3.8)提前了两个版本。3.9怎么了？

视图发布页面没有列出3.9版，也没有列出没有这种版本的原因。

这是我不知道的新的安全规则吗？

Answer 1

我不能确切地说出在这个特殊情况下发生了什么，但是：

在安全更新的情况下，执行双重发布是相当普遍的做法。例如，Core每次都这么做，尽管我现在找不到相关实践的参考。

假设你已经发布了X.Y版本。

在X.Y + 1上，您已经在X.Y之上做了一些提交，现在您在X.Y中发现了一个安全问题，需要解决它。现在，您可以快速地推出X.Y +1以及附加的特性工作和安全修复。

但是，您的新特性工作并没有像它应该的那样经过很好的测试，因为您还没有为安全紧急发布做好准备。所以，尽管它可能运行得很好，但你的工作“比平时更麻烦”。

此外，大型网站在升级版本时可能会非常小心，他们需要花时间测试网站，确保一切都能正常运行。

但是，安全更新过程中的任何延迟都是不好的，因此我们非常希望能够帮助人们尽快升级。

那我们能做什么呢？我们可以只对安全性进行修复，并且只对其单独发布。

在这个特殊的例子中，看起来特性发布是首先完成的，然后是安全发布。如果我想要安全地修补我的3.8，我将不得不取出3.9到3.10之间的差异并应用它。然后，我可以花时间升级到真正的3.10。

如果您查看Core中类似的示例，请检查git log 7.31..7.32，它将向您显示“SA 2014-005”是在10月15日修复的，然而，稍后的版本7.33 (git log 7.32..7.33)将包含10月15日之前和之后的提交。Git的历史被重写了，以至于仅在下一个版本中就完成了安全更新，然后任何额外的工作都进入了新的版本。这需要更多的git欺骗，但进一步降低了升级的门槛。在SA 2014-005的情况下，这是很重要的。在意见问题上就不是那么重要了，因为这是次要的问题。

Answer 2

存储库中肯定有3.9的标记。因此，不管出于什么原因，维护人员决定在3.9发布之前增加次要版本。6.x-2.x和6.x-3.x分支也是如此。