在测试版中预期会发生API变化吗？

Question

在开放源码框架中，在走向新的主要版本的过程中，在beta阶段删除了不受欢迎的API。现在，用户请求还原一些不受欢迎的API，因为它破坏了兼容性。对我来说，beta代表“自己承担风险”。

• 难道不是预期由于一个主要版本的碰撞，API可能会改变吗？
• 在beta阶段更改API“不常见”吗？

Answer 1

正如您已经提到的，您的用户目前正在向新的主要版本抱怨。

难道不是预期由于一个主要版本的碰撞，API可能会改变吗？

要么在API中不进行向后不兼容的更改，要么在一个主要版本的凸起中这样做。如果你没有在一个主要版本的碰撞中这样做，你会在哪里做呢？除非你在一个小版本的凸起中这样做，这显然更不合适。所以基本上，除了一个大版本之外，再没有比这更好的了，对吧？

根据您的API版本控制系统，在主要版本更改中，API更改是预期的还是不期望的。在你的情况下，似乎是这样。这是你自己的决定，尽管很常见。除非你完全不打算做向后兼容的改变。

在beta阶段更改API“不常见”吗？

测试阶段，根据您在文章中指定的用法，可以假定为“发布候选版本的预览”和“未完成”。如果您正在进行向后不兼容的更改，您应该尽快发布它们，以便给API的用户更多的时间来修复兼容性问题。当然，由于明显的原因，在版本升级之前，您不会在版本中这样做(您已经在早期版本中标记了@Deprecated！为什么尽管有警告，人们还是会编译代码？)既然您无论如何都要在发布候选版本中进行这些更改，那么为什么以后要离开它们呢？此外，从技术上讲，你的测试版已经是主要版本了。

这个问题也可以理解为同一版本的两个测试版之前的API变化。只要您要在主要版本中添加这些更改，这就不是一个问题。毕竟，在beta阶段，API更改可以被认为是“尚未完成的更改”。

最后，永远记住:每一次更改都会破坏向后兼容性。

xkcd:工作流 --可能有孩子在外面拿着空格键在冬天里保暖！你的最新消息谋杀了孩子。

Answer 2

从语义版本2.0.0引证

主要版本0 (0.y.z)用于初始开发。任何事情都可能在任何时候改变。公共API不应被认为是稳定的。

因此，如果您将beta称为0.x.x版本，那么是的。总之，考虑到第8节

如果在公共API中引入了任何向后不兼容的更改，则必须增加主版本X (X.y.z \x> 0)。

及第10条

预发布版本表示该版本不稳定，可能不满足其关联的正常版本所表示的预期兼容性要求。

如果你说一个测试版是一个新版本的不稳定版本，那么如果你增加了主要版本，而不是之后，一个不向后兼容的公共API更改将是“合法的”。

我相信许多项目都使用语义版本控制或类似的版本控制方案。无论如何，所说的一切只适用于语义版本控制。如果您遵循自己的版本控制方案，您可以自由地做任何您喜欢的事情，但是如果您继续破坏公共API，使用您的库的人可能会感到沮丧并停止使用它，所以您应该考虑将所有更改保留在一个开发分支中，并且只在您确信公共API中不会有任何更改的情况下才发布一个新版本的beta版。