【Gradle声明版本系列2】声明丰富版本
术语及其含义
Gradle支持丰富的版本声明模型,允许组合不同级别的版本信息。下面解释了术语及其含义,从最强到最弱:
-
strictly:任何与此版本表示法不匹配的版本将被排除。这是最强的版本声明。在声明的依赖项上,strictly可以降低版本。在传递性依赖项上,如果无法选择任何符合此条件的版本,则会导致依赖关系解析失败。有关详细信息,请参见覆盖依赖项版本部分。此术语支持动态版本。
当定义时,它会覆盖先前的require声明,并清除先前的reject。
-
require:表示所选版本不能低于require接受的版本,但通过冲突解决可能更高,即使更高的版本具有一个独占更高边界。这是直接依赖项的转换。此术语支持动态版本。
当定义时,它会覆盖先前的strictly声明,并清除先前的reject。
-
prefer:这是一个非常宽松的版本声明。仅当对模块没有更强的非动态意见时才适用。此术语不支持动态版本。
定义可以补充strictly或require。
当定义时,它会覆盖先前的prefer声明,并清除先前的reject。
除了级别层次结构之外,还有一个额外的术语:
- reject:声明不接受特定版本的模块。如果可选择的版本仅被拒绝,则会导致依赖关系解析失败。此术语支持动态版本。
用例
下表说明了一些用例以及如何组合不同术语进行丰富的版本声明:
可接受的该依赖项的哪个版本? | strictly | require | prefer | rejects | 选择结果 |
---|---|---|---|---|---|
已测试1.5版本,相信所有未来版本都可以工作。 | 1.5 | 等同于 org:foo:1.5,允许升级到2.4。 | |||
已测试1.5版本,根据语义化版本的要求进行软约束升级。 | [1.0, 2.0[ | 1.5 | 等同于1.5,允许升级到2.4。 | ||
已测试过1.5 版本,但遵循语义化版本规范。 | [1.0, 2.0[ | 1.5 | 等同于1.5,如果没有其他人关心,则为1.5。 | ||
与上述相同,已知1.4 版本存在问题。 | [1.0, 2.0[ | 1.5 | 1.4 | 除1.4之外的1.0和2.0之间的任何版本,如果没有其他人关心,则为1.5。 | |
没有意见,与1.5兼容。 | 1.5 | 如果没有其他意见,则为1.5。 | |||
没有意见,偏好最新发布版本。 | latest.release | 构建时的最新发布版本。 | |||
处于边缘位置,选择最新的发布版本,不允许降级。 | latest.release | 最新发布版本,不接受降级。 | |||
没有其他版本,只有1.5。 | 1.5 | 1.5,如果没有其他严格或更高的要求约束,则为任意版本。 | |||
只有1.5的补丁版本。 | [1.5,1.6[ | 最新的1.5.x补丁版本,如果没有其他严格或更高的要求约束,则为任意版本。 |
带有锁定标记(lock)的行表示在此上下文中使用依赖关系锁定是有意义的。还与丰富版本声明相关的另一个概念是可以发布解析后的版本而不是声明的版本。
使用strictly,尤其是对于库来说,必须经过深思熟虑,因为它会对下游消费者产生影响。同时,如果使用正确,它将帮助消费者了解在他们的上下文中哪些组合的库不能一起工作。有关更多信息,请参见覆盖依赖项版本。
注意
丰富的版本信息将保留在Gradle模块元数据格式中。但是,转换为Ivy或Maven元数据格式将有损失。将发布最高级别,即strictly或require而不是prefer。此外,任何reject都将被忽略。
通过在依赖关系或约束声明上使用version DSL方法访问丰富的版本声明,该方法提供对MutableVersionConstraint的访问。
示例
dependencies {
implementation('org.slf4j:slf4j-api') {
version {
strictly '[1.7, 1.8['
prefer '1.7.25'
}
}
constraints {
implementation('org.springframework:spring-core') {
version {
require '4.2.9.RELEASE'
reject '4.3.16.RELEASE'
}
}
}
}
以上是关于声明丰富版本的内容。
16.RELEASE’
}
}
}
}
以上是关于声明丰富版本的内容。
## [参考链接](https://docs.gradle.org/current/userguide/rich_versions.html)