更新依赖项是不是会破坏向后兼容性（semver 主要版本更改）？

Posted 2023-03-07

【中文标题】更新依赖项是不是会破坏向后兼容性（semver 主要版本更改）？

【英文标题】：Does updating dependencies break backwards compatibility (semver major version change)?更新依赖项是否会破坏向后兼容性（semver 主要版本更改）？

【发布时间】：2018-03-16 03:30:25

【问题描述】：

假设我发布了一个新库 Foo v1.0.0，它需要 php 5.6 作为依赖项。

现在我想在一些方法实现内部使用 php 7.0 中的一些较新的语言结构。但是，我的整个公共 API（方法名称、参数、返回等）保持不变。

按照semver，我现在应该发布什么版本号？

在我看来，需要新的主要平台依赖项将破坏运行 php 5.6 的现有用户的向后兼容性，这些用户将无法简单地使用composer update 进行升级，因此现在应该是v2.0.0。另一方面，因为我暴露的 API 没有任何改变，我觉得这应该只是一个补丁 v1.0.1

【问题讨论】：

介意解释一下为什么你问的这么多问题都没有被接受的答案吗？

@MarcinOrlowski 在今天的 60 个问题中，8 个问题没有答案可以接受，7 个问题的答案无法接受，我在 cmets 中提供了反馈。

【参考方案1】：

不，你搞错了backward compatibility 的意思。如果你的库的 API 保持不变，那么它可能只是新的主要版本，但它仍然向后兼容，这意味着升级不需要更改使用你的库的代码。要求 PHP 7 只是要求，但它没有任何兼容性。

我看到的其他项目通常会出现重大数字冲突，但这主要是因为它们只改变了需求，但也做了一些改变以受益于新的 PHP 功能。所以问问你自己，你是否真的会从只需要 PHP 7 中受益，或者这将是一种表面上的改变或代码清理。这还取决于您的更改将真正影响多少用户。

编辑

要求 PHP 7 有时会带来巨大的变化，因为许多人仍在使用 5.x 并且不想或无法升级，虽然这不是这里的向后兼容性问题，但我会将其设为 2.0.0清楚地表明这一变化是重大的。

【讨论】：

感谢您抽出宝贵时间，但我发现您的回答比澄清更令人困惑。我真的不清楚您是在暗示您的答案是 2.0.0 版还是 1.0.1 版。你说不，但它仍然可能是一个主要的版本更改。我希望我清楚地解释了我的情况关于“只需要 PHP 7 的好处，否则它将是一种外观更改或代码清理”我真的很抱歉延迟提供反馈。感谢您的考虑。

use some of the newer language constructs in php 7.0 internally within some of the method implementations 的真正好处是什么？另外，有多少人使用你的图书馆？

真正的好处是抽象在API背后，重构，代码可读性等等。我不知道有多少人在使用API​​，但这确实与semver没有任何关系。

我想说将依赖项升级到另一个主要版本需要进行重大升级。这样做的简单原因是依赖关系（此处为 PHP）既可以通过 Foo 间接发生，也可以直接发生。因此，升级Foo 需要我更改我的其他代码以使其与较新的 PHP 版本兼容。当我在这里偶然发现这个相关问题时，我目前 (***.com/questions/48158317/…) 试图为该问题找到不同的解决方案。