为什么 LATEST 是依赖管理反模式？

Question

我最近在进行代码审查（针对我的代码），一位架构师在我的 build.gradle 文件中看到以下内容：

dependencies {
    compile 'org.apache.commons:commons-lang3:3.3.2'
    compile 'org.apache.httpcomponents:httpclient:4.3.2'
    compile 'com.fasterxml.jackson.core:jackson-annotations:2.3.0'

    // The problem:
    compile 'org.ourcompany:widget-client:LATEST'
}

对此他说：“使用LATEST是一种依赖管理反模式，不要这样做。”我很想问“为什么？”，但我没有。

我这样做是因为 widget-client JAR 版本每个月更改多次，并且试图记住用最新版本号更新我的 Gradle 构建变成了一场噩梦。更糟糕的是，由于我们没有最新的 widget-client 版本，我浪费了很多时间进行调试和故障排除。所以这是我的解决方法。

在我使用 LATEST 为我们进行反击和游说之前，我想充分了解情况。也许架构师是正确的，在这种情况下，我想知道为什么，更重要的是，解决方案是什么（所以我不知道必须每周两次更新我的 Gradle 版本）。如果他不正确，我想知道一些原因。

我的另一个想法是，也许可以将 widget-client 的特定版本标记为 STABLE，然后我们就可以随时获取最新的 [=它的 17=] 版本，可能比 LATEST 好，但也许不是......这样，至少，我们总是有一个客户端版本是稳定并且被认为是功能性的和经过良好测试的，这使我们远离（可能有错误的）前沿，但仍然给我一个 STABLE 标签，所以我不必继续将 deps 更新到特定版本。

这真的都归结为为什么 LATEST 不好。如果它是因为它让你一直处于最前沿（并因此出现错误），那么我认为 STABLE 解决方案是可行的方法，但我对这些东西的了解还不足以完善一个具体的解决方案。如果 LATEST 由于其他原因不好，或者根本不坏，那么我也不确定该怎么做。想法？

Answer 1

这很糟糕，因为它使构建不可重现。如果您运行几天后使用相同的源构建相同的版本，结果可能会有所不同，因为使用了另一个版本的依赖项。

如果这种依赖依赖于其他库，那么情况会变得更糟，而这些库可能也会更改其版本并可能与您的库发生冲突。

所以实际上，当您使用 LATEST 时，您不需要管理依赖项。

为什么 LATEST 是依赖管理反模式？

Why is LATEST a dependency management anti-pattern?

gradle

versioning

dependency-management

anti-patterns