上下文
我有一个项目(A)依赖于另一个(B)，两者都使用Gradle构建系统。项目A通常声明对特定版本的B的依赖。当修改项目B时，可以方便地立即查看对项目A的影响。在命令行上使用settings.gradle或--include-build中的includeBuild，项目A的构建被重新配置为包括项目B的本地开发版本，而不是已发布的工件("复合构建")。然而，项目B的本地副本声明了一个开发版本号，而不是项目a请求的稳定发布版本。为了确保包含的B版本满足a中声明的依赖项，我一直在更改a，以请求类似org.example:B:[v6, )而不是org.example:B:v6.0的版本范围。然而，我看到即使A指定了与B不对应的无意义版本号，构建也会成功。
问题
版本如何影响此依赖项替换过程？
研究
我阅读的文档(链接如下)显示了如何包含构建，但没有提到版本号。https://docs.gradle.org/current/samples/sample_composite_builds_basics.htmlhttps://docs.gradle.org/current/userguide/composite_builds.html#defining_composite_builds
一些提示可能出现在该页面上；暴力"；依赖解析的修改：
在复合构建中，必须与不应用请求的依赖属性：当使用复合时，Gradle将自动匹配请求的属性。在其他换句话说，如果您包含另一个构建，那么您就是用等价物替换被替换模块的所有变体包含的内部版本中的变体。
尽管这涉及"；变体"；以及他们的"；属性"；，根据依赖性术语文档，这似乎与模块版本控制不同，该语句似乎是相关的。对于依赖模块版本，可以说类似的话吗？
答案：很可能不是
在这一页上写着(强调我的)：
Gradle将检查组和名称中包含的构建中的项目，并用项目依赖项替换与${project.group}:${project.name}匹配的任何外部依赖项。
同样，在这个页面上(强调我的)：
Gradle将检查组和名称中包含的构建中的项目，并用项目依赖项替换任何匹配的外部依赖项。
这些是我能找到的关于这个话题的唯一引文，不幸的是，它们很模糊。我们可以看出，替换与组和名称一起使用，并且没有提到版本这个词。事实上，正如你和我都进行了经验测试，我们知道指定版本没有任何相关性。
我们不希望版本有什么影响
想一想这有点道理。替换来自本地源——隐含地说，是不断发展的开发人员版本，或者是修补的版本。但肯定不是二进制版本。
这确实是我们有意识的选择。因为我们用includelocalbuild指令指定了替换，我们得到了我们所要求的。如果我们想让版本变得重要，那么我们就不能替代，瞧，Gradle必须出去获得版本化的二进制版本。
而且这永远都不重要
更进一步，Gradle的工作方式会有所不同吗？我很怀疑。因为源代码中指定的版本本质上是不可靠的。这是我们上次构建和发布的版本，还是我们计划发布的下一个版本？也许Gradle应该能够跟踪本地文件系统的更改，并以某种方式试探性地验证版本！
从版本到实际源代码的唯一映射是Git标记。这为大量的复杂性打开了大门⚠️