想象一下，有一些框架X以及为此框架开发的模块A和B。另外，A取决于B（允许使用B的任何版本）。最初，A v.10和B v1.0是为X v1.0开发的。
B和A会定期发布新版本。这将导致当我更新A时，B也将被更新。假设已经过去了几年，现在我们的存储库中有A的v3.0和B的v6.0（并且A和B仍适用于X v1.0）。
现在，我们有一些本地安装保持了原始状态（X，A和B均为v1.0）。因此，如果我此时更新A，最终将把A更新为v3.0，将B更新为v6.0。但是，假设我在X v2.0发行之前没有运行此更新。
现在，框架X v2.0已发布，并且与X v1.0不兼容。B的供应商随后发布了X v2.0的B v7.0。但是，A的供应商尚未针对X v2.0对其进行更新。将A更新到v3.0的尝试将导致尝试将B更新到v7.0的操作不起作用，并且升级过程将终止。
我想要的是将A更新到3.0将导致将B更新到v6.0，因为它是X v1.0的最后一个兼容版本。
如果在A中存在依赖项“ B 1.x”，那么当X v2.0的B v2.0出现时，这将保护我免受问题的困扰。但是，当它获得仍可以与X v1.0兼容的新的主要发行版时，我将无法获得B的更新。这意味着如果模块供应商仍在X v1.0框架上运行，则无法制作v2.0，对B的所有更新都必须为v1.x。
因此，我最好有独立于X框架版本设置模块版本（包括主要版本）的自由。我需要一种机制来解决依赖关系，即仅在与当前环境兼容的情况下才安装依赖关系的最新版本。如果不兼容，则会选择最新的兼容版本，而不是停止整个过程。
可以“告诉” Composer“在当前条件下可以更新到最新版本”，而不是简单地“更新到最新版本”吗？
首先需要了解版本控制语义。简而言之：
版本： X.Y.Z
在哪里：
https://getcomposer.org/doc/articles/versions.md
因此，如果您写：
例如： ^1.2.3
它将库更新为最新版本，包括新功能（例如：1.*.*）（但将保留相同的主要版本，例如，如果可用，它将更新为1.4.5）
~1.2.3更为严格，这将只更新bug修复版本（例如：1.2.*）
但是，不幸的是，并非所有库都遵循版本语义，因此无论如何您都必须检查更新结果。
但在两种情况下，最低要求的版本是： 1.2.3
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句