包主版本更改是否应该意味着子包主版本更改？答案

【问题标题】：Should a package major version change mean a sub-package major version change?包主版本更改是否应该意味着子包主版本更改？
【发布时间】：2020-04-02 11:55:24
【问题描述】：

假设我有一个核心 CMS，它已从 v4.8.7 升级到 v5.0.0

我还有一个带有自己的版本号 1.2.4 的事件模块包，它将这个核心 CMS 包导入到它的 composer.json 文件中：

    "company-name/cms": "^4.3",

我将这个包上的composer.json文件升级为：

    "company-name/cms": "^5.0",

但是如何使用语义版本控制来标记这种变化？

应将其标记为重大更改，从而意味着子模块版本号将变为2.0.0，还是应将其标记为次要/补丁？

我认为需要将其标记为重大更改，否则如果父包已过期但只是想收集意见，则在使用该包的项目上运行 composer update 可能会导致错误。

【问题讨论】：

存在不同的理念，我认为大多数人会认为这是一个重大变化，尽管从技术上讲并非如此。一个安全的方法是支持你的包中的两个版本，例如^4.3|^5.0。从纯粹的角度来看，这不是一个重大变化，因为 composer 将确保您的新软件包版本永远不会安装在 4.3 中。重大更改在于您的依赖项，但您的代码没有任何重大（代码）更改。

标签： php composer-php semantic-versioning

【解决方案1】：

从纯粹的 SemVer 角度来看，这实际上取决于工具链功能和约定，以及传递依赖项中破坏性更改的类型。

某些工具链会阻止包含破坏性传递依赖项的非破坏性更新，发出警告，并且不会破坏您的客户摄取和构建过程，如果；他们可以通过跳过不间断更新来完成构建的依赖关系图。其他人会抛出错误，并阻止构建完成。

然而，构建中断并不是唯一的传递依赖问题。如果你引入一个传递行为，它会修改你的组件的有效功能，以至于你的客户代码在运行时会中断，你会很痛苦。对于阻止此类更新发生的工具链，这当然不是问题。

设身处地为您的客户着想，想想他们可能会使用哪些工具链来提取您的包裹。你愿意给他们多少痛苦？

【讨论】：