Okhttp: Be smarter about transitive dependency upgrades == kotlin-stdlib-common

[kebeda]

This is the second time this has happened in the last few updates, so I would like to bring to your attention so you can be mindful of it in the future:

In okhttp3:okhttp:4.6.0 you changed the dependency on org.jetbrains.kotlin:kotlin-stdlib to version:1.3.71. okhttp3:okhttp:4.6.0 also has a dependency to okio:okio:2.6.0, which itself has a transitive dependency to org.jetbrains.kotlin:kotlin-stdlib-common:1.3.70.

Notice that these versions of kotlin-stdlib DO NOT MATCH. This causes the maven-enforcer-plugin to fail because of the ambiguous dependencies.

Please, please, please, in the future, when you update a transitive dependency shared by both okhttp and okio, could you please make sure they all AGREE on all their transitive dependencies? For now, you can fix this bug by release a new version of okhttp that has a new version of okio which has a dependency on org.jetbrains.kotlin:kotlin-stdlib:1.3.71, THE SAME AS WHAT YOU CHANGED in okhttp3:okhttp. This will make the maven-enforcer-plugin happy again.

Thank you.

[JakeWharton]

There's nothing wrong with doing this. The stdlib is forward compatible. The assumption here is that we will always release Okio near OkHttp which is unlikely to be true.

It's not clear why releasing a new version of Okio would solve anything unless we also released a new version of OkHttp with that version. Otherwise you would need to depend on that new Okio explicitly which would make OkHttp and your project disagree.

The whole point of version resolution semantics in tools like Aether and Gradle and semantic versioning is so that we explicitly don't need to do things like this.