这里的基本问题是使用分支（devmaster）而不是标记版本。使用分支很可能会导致问题。我正在观看有关Stackoverflow的Composer问题，每当有人报告包出现问题时，他们99%的时间都在使用开发分支和“最小稳定性：开发”。

发生什么事了？我必须假设您想第一次安装这些包。所以Composer不安装，而是更新包。否则，能够满足所有版本要求的工作版本集将被记录在composer.lock中。

这里是依赖情况：两个包依赖于第三个包，但是这两个包需要不兼容的版本。

你能修好它吗？本地composer.json文件中只有一个工具能够安装第三个包：使用内联版本别名安装它。

"require": {
    "anahkiasen/former": "dev-master",
    "vespakoen/menu": "dev-master",
    "anahkiasen/html-object": "dev-master as 1.1.2" /* add this line */
}

通过安装dev master分支并将其声明为1.1版。2、Composer可以解析两个包的依赖关系。

问题是，当你有三个不同版本的第四个包时，它就会失败。

正确的做法是每个开发分支在其编写器中包含一个分支别名声明。json，这将允许Composer检测到dev master分支实际上相当于1.1版。x、 这在这里可能会有所帮助（但如果任何包明确要求给定的版本号-1.1.x不是1.1.2，则不会）。添加分支别名仍然是一件好事，应该这样做。如果维护人员希望避免在composer中持续维护此硬编码版本别名。json，他们也可以在一个分支中开发该版本。以其名称命名的x版本（即Composer将检测到“v1.1.x”或“1.1.x”包含开发稳定性中的所述版本）。

请注意，我在最后一段中描述的问题是，包明确要求给定的版本号。使用这种方法，如果您需要这样一个包，您不能自己或在不同的包中使用该依赖包的不同版本。虽然可能存在只需要一个版本的情况，但更好的解决方案是需要版本范围。

我个人倾向于对大于1.0的版本使用插入符号运算符：^1.1.7需要1.1.7作为最低版本，但不会更新到任何版本2.0.0，这被认为具有不兼容的更改。如果一个包根据语义版本控制被仔细标记为新版本，这就像一个魅力。您永远不会对不兼容的更改感到惊讶（当然，除非人性干扰，但您应该能够检测到此故障，并在软件中断时回滚更新）。

对于低于1.0的版本，请注意插入符号操作符的工作方式不同于平铺操作符-有关更多详细信息，请参阅手册。对于在我控制下标记为0的包，我确实更喜欢tilde。以获得“兼容”功能更新，即使语义版本控制允许在0中进行不兼容的更新。x范围。

但是即使没有语义版本控制，版本号中的每一点不准确都有帮助，比如定义1.1。*（据说将更新到所有即将发布的错误修复版本）或

最糟糕的事情是需要“开发大师”。虽然这确实是非常不准确的（它将解析到分支中任何可能的提交，这取决于您更新的时间），但问题是，除非您确切地知道您需要哪个提交id，否则您无法返回到以前的dev-master版本将此需求添加到composer.json。但是接下来你会处于与上面完全相同的情况，需要一个精确的版本（git标签只是一个提交id的命名别名）。