Incompatible Kotlin Version Error with OkHttp v5.1.0

[satyakaikala]

I'm encountering an error when using OkHttp v5.1.0 with Kotlin v2.0.21. The error message is as follows: "Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 2.2.0, expected version is 2.0.0."

Environment

• OkHttp version: v5.1.0
• Kotlin version: 2.0.21
• Kotlin Compiler options: kotlin.compilerOptions.languageVersion = 1.9, kotlin.compilerOptions.apiVersion = 1.9

Steps to Reproduce

1. Set up a Kotlin project with the above compiler options.
2. Add OkHttp v5.1.0 as a dependency.
3. Attempt to compile the project.

Additional Information The issue does not occur with OkHttp v4.12.0.

[JakeWharton]

The use of Kotlin 2.2 to compile is noted in the change log: https://github.com/square/okhttp/blob/master/CHANGELOG.md#version-500

That being said, we could target a slightly older version, but I'd be hesitant to provide strong guarantees here.

[yschimke]

Would we need to coordinate with okio also?

It is probably a good idea to define the policy even if it's latest on the day it's released.

[satyakaikala]

@JakeWharton, I appreciate the reference to the change log. I was wondering if there was a specific reason why certain compiler options, such as languageVersion and apiVersion, were not set to ensure compatibility with earlier versions, like 2.0.

I would like to suggest setting specific compiler options to facilitate smoother adoption across the industry. Given that the adoption of new Kotlin versions can be slower in some projects, it would be beneficial to consider the following recommendations:

1. Set Minimum Compiler Options: languageVersion: Consider setting this to a minimum of 2.0 to ensure compatibility with projects that are not yet on the latest version. apiVersion: Align this with the languageVersion to maintain consistency.
2. Support N-2 Releases: By supporting N-2 releases, OkHttp can provide a more gradual upgrade path for developers, allowing them to adopt new versions at a manageable pace.

[JakeWharton]

It's simply never been a problem.

We're aware of how it works and what it changes, thanks. It's not quite that simple, though, because we also have dependencies.

[hugoncosta]

+1 on this - I'd really appreciate having 2.0 as the minimum compiler version. We have thousands of Kotlin packages, we cannot always be on the latest and greatest. For 2.2.0, the lowest version you can target is 1.6, but I think 2.0 is a sensible target while it lasts. Ktlint did that recently in https://github.com/pinterest/ktlint/pull/3063

[yschimke]

Start with Okio, and we can follow their lead. Without that, this is pointless.

[MukjepScarlet]

I agree this. Because I used OkHttp in a project (with Kotlin 2.0.21), and 5.0.0-alpha.16 is compatible but 5.0.0 is not.

[swankjesse]

I'm confused by the motivation on this one. We have old releases that work on old Kotlin versions, and new releases that work on new Kotlin versions.

Can you pick whichever version works for your Kotlin release?

We will backport security fixes to old releases if that comes up.

[hugoncosta]

If the project is compatible with Kotlin 2.0, why should it compile in a way that it doesn't work? I understand your point - you didn't update any existing version and made it incompatible. If people want the newest features, they can just upgrade to Kotlin 2.2 and the newest version of the library. But why should OkHttp force that?

Example - let's say I have a project that needs the latest OkHttp but Kotlin 2.2 has a bug that will only be fixed in 2.3. With the current set up, I'll have to find a workaround to either bypass the Kotlin bug, port the feature code of OkHttp into my code or compile from source with 2.0 compatibility.

We keep a single active version of OkHttp and a single active version of Kotlin 2.0. Due to several reasons, we're still stuck in 2.0.21. This would make our life easier with little to no impact on the OkHttp side.

[rschmitt]

Is it customary in the Kotlin ecosystem for low-level dependencies to perform frequent major version bumps so that they can aggressively track the latest version of Kotlin?

[JakeWharton]

Low-level is a matter of perspective, but otherwise no. Kotlin bumps don't require or warrant major version bumps.

We should do this because it's easy and we can until we can't. And at that point it becomes real easy to say that it becomes on you to upgrade Kotlin, too.

[kingargyle]

Dagger just recently had to do a point release to address similar issue of not requiring everybody to upgrade to use their version that was compatible with Kotlin 2.2

https://github.com/google/dagger/releases/tag/dagger-2.57.1

One other concern here is that the current version okio that is officially released is 3.10.2 on github. Yet okhttp is using 3.16.0. That is more sn issue with okio and not updating the releases even though changelog is updated.

I understand any roll back or fix would require okio to also fix similar issues, at a corporate level it is like hearing cats to get people to adopt latest and greatest kotlin level.

Google Dagger is probably as, wide spread and used as the square stack of frameworks over the last decade.

[JakeWharton]

I have deleted the Okio releases to avoid confusion