-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace failOnVersionConflict() with custom requireUpperBoundDeps #8238
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The buildscript change looks cool.
I'm going to wait until #8243 is in to resolve the build failure. I'll end up adding a direct dependency on error-prone from grpc-netty; right now it is getting error-prone transitively from Guava. |
failOnVersionConflict has never been good for us. It is equivalent to Maven dependencyConvergence which we discourage our users to use because it is too tempermental and _creates_ version skew issues over time. However, we had no real alternative for determining if our deps would be misinterpeted by Maven. failOnVersionConflict has been a constant drain and makes it really hard to do seemingly-trivial upgrades. As evidenced by protobuf/build.gradle in this change, it also caused _us_ to introduce a version downgrade. This introduces our own custom requireUpperBoundDeps implementation so that we can get back to simple dependency upgrades _and_ increase our confidence in a consistent dependency tree.
The changes didn't introduce a bug. It is just we previously excluded and re-defined errorprone with guava such that it would be closer to the root and ended up beating protobuf-java-util's dep.
…ying on Guava's transitive dep
1052e18
to
1443ffc
Compare
Looks like #8243 did indeed solve the build failure. |
failOnVersionConflict has never been good for us. It is equivalent to
Maven dependencyConvergence which we discourage our users to use because
it is too tempermental and creates version skew issues over time.
However, we had no real alternative for determining if our deps would be
misinterpeted by Maven.
failOnVersionConflict has been a constant drain and makes it really hard
to do seemingly-trivial upgrades. As evidenced by protobuf/build.gradle,
in this change, it also caused us to introduce a version downgrade.
This introduces our own custom requireUpperBoundDeps implementation so
that we can get back to simple dependency upgrades and increase our
confidence in a consistent dependency tree.
The main
build.gradle
is where the real changes are, but the rest wouldhave been easy to introduce an accidental bug/change.
CC @elharo