gradle 中的版本范围

Question

在 gradle 依赖项中指定版本范围的可能方法是什么？我看到了一些 1.+ 符号，但我还没有找到真正说明什么是可能的，什么是不可能的文件。此外，我不知道是否也可以使用 Maven 范围。

谁能给我一个简短的概述，以便我理解规则？

Answer 1

“Gradle Dependency Management”一书在 p.从图 12 和 13 可以看出，除了 + 符号（2.1.+ 表示从 2.1.0 到 2.2.0 的范围）之外，您还可以使用 Ivy 符号来表示形式的开闭区间

[1.0,2.0]
[1.0,2.0[

也可以

[1.0, )

对于“从 1.0 开始的所有版本”。

Answer 2

首选替代方案

使用 Ivy 表示法指定版本范围。以下是从this web page复制的一些示例：

• [1.0, 2.0]: 所有版本 >= 1.0 和
• [1.0, 2.0[: 所有版本 >= 1.0 和
• [1.0, ) : 所有版本 >= 1.0 // avoid. Unbound is dangerous!

麻烦的替代方案

在主要、次要或补丁号中使用“+”。这种方法至少有两个问题：

• 如果您正在构建 lib 并生成 pom 文件，则 pom 将与 maven 不兼容，除非您应用一些解决方法来解析版本并防止 pom 依赖项在版本元素中使用“+”。见this Gradle github issue。
• “+”的含义容易混淆。好吧，也许不是，但请四处询问，看看您的所有同行是否确切知道 1.1.+ 和 1.1+ 在 gradle 依赖项中的区别。

理想的选择

完全避免动态依赖（使用“+”或版本范围）。相反，使用固定的版本依赖关系并经常通过良好的测试更新版本。原因如下：

• 在过去，向后兼容是神圣的。现在不是这样了。新版本经常移动/删除/重命名类和函数。
• 如果您的依赖项是动态的（尤其是使用“+”或未绑定范围），下一个构建可能会选择与您的项目不兼容的新版本。不兼容只能在 rutime 时检测到。
• 如果一个库的依赖项是动态的并且一夜之间发布了新版本，那么今天构建的库的版本 X 可能与明天构建的库的版本 X 不同。这种程度的不确定性对于图书馆来说是不可取的。