升级库时语义版本更改(应用程序)

Question

所以我有一个应用程序，它使用了14个不同的库。我已经有一段时间没有更新这个应用程序了，所涉及的一个或多个库已经经历了一次重大的修订(使用语义版本控制)。尽管如此，我刚刚更新了应用程序，以利用这些库的所有最新版本。

此外，项目中涉及的库所经历的一个主要更改是接口方法名称发生了更改。应用程序使用的是该接口方法，所以现在我必须在调用函数以匹配新库的地方更改它。这无疑是库中的一个重大更改，但我认为这并不是应用程序修订版的重大更改。

我的推理正确吗？应用程序得到什么样的修改？

Answer 1

语义版本控制规则从用户的角度应用于您的软件。如果您的API已更改且不兼容，则应更新主要版本号.但听起来不是这样的。听起来您的API并没有改变--使用您以前版本的客户端可以在没有任何其他更改的情况下直接进入新版本。这将是一个轻微的版本增加。

这一点在语义版本化常见问题中得到证实：

如果在不更改公共API的情况下更新自己的依赖项，该怎么办？这将被认为是兼容的，因为它不影响公共API。显式依赖于与包相同的依赖项的软件应该有自己的依赖关系规范，并且作者会注意到任何冲突。确定更改是修补程序级别还是次要级别修改取决于您是否更新了依赖项以修复bug或引入新功能。对于后一种情况，我通常期望得到额外的代码，在这种情况下，这显然是一个次要的级别增量。

根据这些注释，您似乎正在为应用程序使用语义版本控制。这不是一个典型的用例。语义版本控制是为API和库设计的。这里还有一个关于软件工程堆栈交换解决应用程序中语义版本控制的使用问题。的问题。

在基于GUI的应用程序实例中，GUI是您的公共界面。我会使用这样的定义：

• 当您更改用户的工作流程或用户如何以向后不兼容的方式与您的软件交互时，主要版本。
• 以向后兼容的方式添加功能时的次要版本
• 当您进行向后兼容的bug修复时，修补程序版本。

如果在不更改现有工作流的情况下添加功能，则这是一个次要版本。如果您改变了现有的工作流，这是一个主要的版本。补丁版本是不改变用户与软件交互方式的bug修复。

Answer 2

如果您在库中的公共接口上更改了公共方法名，则可以。这是一个重大的版本变化。

为什么？因为升级库的用户如果使用任何旧的方法名，就会有非编译代码。

通常，您在自己的代码中引用的第三方库不会向库的用户公开，因此不管它们是否有重大或次要的更改，您只需要对代码进行点发布。

仅仅为了与第三方库的命名方案匹配而更改您的接口可能不是个好主意