It depends on the build tool, not on which team argues better. Maven uses the version nearest to your project in the tree. Go selects the highest version any module requires. Tools that allow nested copies can keep both. Know your tool's rule before you debate versions.
The rule differs by ecosystem
Teams often assume the newest version wins everywhere. That is not true, and the difference matters for security fixes.
| Ecosystem | How a conflict is resolved | Source |
|---|---|---|
| Maven | Nearest definition wins. At equal depth, the first declaration wins. | Maven dependency mechanism guide |
| Gradle | Constraints take part in conflict resolution and usually mean at least this version. | Gradle dependency constraints guide |
| Go | Minimal version selection builds the list from the highest version any requirement names. | Go modules reference |
The Maven guide gives a clear example. If your project depends on A, A depends on a deep chain that needs D 2.0, and another dependency needs D 1.0 at a shorter path, then D 1.0 is used. The older version wins because it is closer.
Why this causes disputes
Say team Red wants version 2 of a parser for a fix. Team Blue's library asks for version 1 and has not been tested on version 2. In Maven, whichever path is shorter may decide the outcome, with no one having chosen it.
That is the real problem. The result can change when someone adds a dependency elsewhere and shifts the tree. A fix that held last month can quietly disappear.
How to take control of the outcome
Make the choice explicit in the one place your tool honors.
- Maven. Declare the version directly in your project, or set it in dependency management. The guide says dependency management takes precedence over mediation for transitive dependencies.
- Gradle. Add a constraint with a short reason, such as the advisory it fixes.
- Go. Raise the requirement in your own go.mod. Minimal version selection then keeps at least that version.
Then check the result with the tool's own tree command rather than trusting the manifest. The Maven guide recommends the dependency tree and analyze goals for this.
Settling the team disagreement
Run a short test instead of a meeting.
- Bump to the fixed version in a branch.
- Run both teams' test suites against it.
- If both pass, the higher version wins and the dispute is over.
- If Blue's tests fail, Blue owns a fix or a documented exception, with a date.
This turns an opinion fight into evidence. It also leaves a record of why the version was chosen.
When both versions must exist
Some toolchains allow two copies of a package in the same tree. That can look like a clean compromise, but it doubles the surface you must patch and can cause subtle bugs if the two copies exchange objects. Treat it as a temporary state, and list it as a known duplicate with a plan to merge.
Quick check
Does the newest version always win a conflict?
No. Maven prefers the nearest definition, and the result depends on tree depth. Go picks the highest version that some requirement names, not the latest release.
How do we stop a fix from silently disappearing?
Declare the version explicitly where your tool honors it, and add a check in CI that fails if the resolved version drops below the fixed one.
Sources
- Maven: Introduction to the Dependency Mechanism
- Gradle: Dependency constraints
- Go Modules Reference: Minimal version selection
Last reviewed: 19 October 2026.
