Unify OkHttp dependency catalog entries - #12201
Conversation
There was a problem hiding this comment.
Minimum and latest instrumentation behavior passes today, but the new global aliases couple compatibility floors to unrelated smoke-test dependencies. That contradicts the project’s instrumentation dependency rule and could silently remove 2.2/3.0 boundary coverage during a future catalog bump.
📊 Validated against 10 scenarios · Open Bits AI session
🤖 Datadog Autotest · Commit ac8b2b7 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
|
|
||
| dependencies { | ||
| compileOnly(group: 'com.squareup.okhttp3', name: 'okhttp', version: '3.0.0') | ||
| compileOnly libs.okhttp3.minimum |
There was a problem hiding this comment.
Keep instrumentation minimums module-local
A future catalog bump could stop testing an advertised minimum and allow newer API usage that fails for customers on that version.
Assertion details
- Input: A maintainer raises
okhttp3-minimumorokhttp2-minimumfor the smoke-test applications without intending to change instrumentation support. - Expected:
Per the repository’s explicit Gradle guidance, instrumented-library compatibility floors should remain exact and local to each instrumentation module. - Actual: The OkHttp 3 compile and minimum-test bounds now read a global catalog value also used by smoke-test modules. The same coupling was introduced in the sibling OkHttp 2 module. The complete fix is to restore local
3.0.0values for OkHttp 3 compile/strict/preferred bounds and local2.2.0values for both OkHttp 2 declarations; existing test sources need no changes because the minimum/latest suites already exercise these boundaries.
Was this helpful? React 👍 or 👎
🤖 Datadog Autotest · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
| okhttp2-minimum = "2.2.0" | ||
| okhttp3-minimum = "3.0.0" |
There was a problem hiding this comment.
🔨 issue: okhttp2-minimum / okhttp3-minimum versions and libraries are instrumentation specific. I would rather keep the main version catalog for core and platform components.
What about creating a dedicated lib catalog for the related libraries if you need to share some version numbers?
What Does This Do
Centralizes OkHttp and Okio versions in the catalog and replaces repeated coordinates with named aliases.
Motivation
Improve catalog naming and unify the minimum, testing, and Datadog-fork versions used across modules.
Additional Notes
Validated by GitLab pipeline #130626366. No public behavior changes.
Contributor Checklist
Jira ticket: N/A