How do 'nearest wins' and 'highest version wins' differ as strategies for mediating conflicting transitive dependency versions, and what's a concrete trade-off between them?

## What mediation means Mediating a version conflict means: the build tool sees two or more different requested versions of the same library coordinate within the dependency graph and needs to pick exactly one to actually resolve and place on the classpath. There are two dominant families of strategy for making that pick, and the choice has real operational consequences. ## The two families - **Nearest-wins**, the strategy Maven uses by default, treats the dependency graph as a tree rooted at your project and picks whichever occurrence of the conflicting library sits at the shallowest depth from the root, with ties broken by declaration order. It is purely structural: it never looks at the actual version numbers being compared, only at where in the graph each was found. - **Highest-version-wins**, which is the default in Gradle, instead compares the actual version identifiers across every occurrence found anywhere in the graph, regardless of depth, and selects the greatest one according to version ordering rules. Depth is irrelevant; only the number matters. ## Why each exists - **Nearest-wins** gives an unambiguous, cheap-to-compute, and easily overridable rule — if you don't like the transitive pick, add your own direct dependency and you automatically win by virtue of being at depth 1. It doesn't require the resolver to reason about semantic compatibility at all, which keeps the algorithm simple and its results explainable purely from graph shape. - **Highest-version-wins** exists because it encodes a different, arguably more realistic assumption: that dependency authors follow semantic versioning, so a newer version is very likely to be a compatible superset of an older one's API, and thus the safest choice when multiple consumers need a library is to give everyone the newest version anyone asked for, satisfying the union of stated requirements more often than an arbitrary graph-position pick would. ## Weighing one against the other Trade-offs, stated on both sides: | | Nearest-wins | Highest-version-wins | |---|---|---| | **Selling point** | predictability and cheap developer control | it usually avoids the 'too old' failure mode automatically, without requiring every team to manually pin the newest version | | **Its cost** | it is agnostic to compatibility — it can easily select an old version over a newer one that a deep transitive dependency actually needs, producing a build that compiles fine but breaks at runtime | it trusts the ecosystem's semver discipline, which is not always honored | A maintainer can publish a 'minor' release that accidentally breaks behavior, and highest-version-wins will promote your entire build to that broken version with no signal, purely because some unrelated transitive dependency happened to bump its own requirement. It's also less sticky: because the winner is a function of the numerically greatest version anywhere in the graph, adding an unrelated new dependency next month can silently shift which version of a shared library your project resolves to, changing behavior without anyone touching the library in question directly — sometimes called **version drift**. ## How each one breaks Failure modes in production differ correspondingly. - Under nearest-wins, the classic failure is a runtime `NoSuchMethodError/ClassNotFoundException` because an old, shallow version won over a transitive requirement for something newer. - Under highest-version-wins, the classic failure is a subtler behavioral regression: the build silently upgrades to a newer transitive version that changes default behavior or has an actual bug, and nobody explicitly asked for that upgrade — it just fell out of someone else's transitive requirement plus the highest-wins rule. ## The same graph, two answers Concrete scenario: consider a Java service built with Gradle. 1. Library A requires Jackson >= 2.12, and library B requires Jackson >= 2.15. 2. Under highest-version-wins, Gradle looks at all requested versions and resolves to the highest one satisfying the comparisons, so both A and B get a version that satisfies their stated minimum. 3. Now picture the same graph resolved by a nearest-wins tool: if A is declared before B at equal depth, tie-break rules (not version comparison) decide, and the result could easily be 2.12 — satisfying A's need but violating B's, since B needed 2.15's newer API. This is why Gradle's approach is often described as friendlier for large transitive graphs, while Maven's is described as friendlier for explicit, auditable control — and why teams working with either tool learn to add explicit dependency management constraints regardless of the default strategy.