想象一下，为此框架开发了一些框架X和模块A和B.此外，A取决于B（允许的任何B版本）。最初，A v.10和B v1.0是为X v1.0开发的。
B和A定期发布新版本。这将导致我更新A时，B也会更新。让我们假设几年过去了，现在我们的存储库中有一个v3.0的A和V6.0的B（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中存在依赖性＆＃34; B 1.x＆＃34;，这将保护我在X v2.0的B v2.0出现时不会出现问题。但是，当它获得仍然可以与X v1.0兼容的新主要版本时，我无法获得B的更新。这意味着模块供应商如果仍在X v1.0框架上运行，则无法生成v2.0，对B的所有更新必须为v1.x。
因此，我可以更自由地将版本设置为模块（包括主要版本），而不依赖于X框架版本。我需要一种机制来解决依赖关系的方式，只有当它与当前环境兼容时才会安装最新版本的依赖关系。如果它不兼容，将选择最新的兼容版本，而不是停止整个过程。
有可能告诉＆＃34;作曲家＆＃34;更新到当前条件下可能的最新版本＆＃34;而仅仅是＆＃34;更新到最新版本＆＃34;？
答案 0 :(得分：1)
首先需要了解版本控制语义。简而言之：
版本：X.Y.Z
其中：
https://getcomposer.org/doc/articles/versions.md
所以如果你写：
例如：^1.2.3
它会将库更新为最新的功能，包括新功能（例如：1.*.*）（但它将保持相同的主要版本，例如，如果可用，它将更新为1.4.5）
~1.2.3更严格，它只会更新错误修复版本（例如：1.2.*）
但是，遗憾的是并非所有库都遵循版本语义，因此无论如何都必须检查更新结果。
但在这两种情况下，所需的最低版本为：1.2.3