Hi :wave: . Looks like compiling a native lib with...

# kotlin-native

[mbonnin]

Hi 👋 . Looks like compiling a native lib with 1.7 requires consuming it with 1.7 (or we get a Incompatible abi version )
1. is that true?
2. could we allow consumption with 1.6 by adding languageVersion = "1.6" when compiling? Looks like this works for JVM but not for native?

[Jeff Lockhart]

I believe this is what kotlin.mpp.enableCompatibilityMetadataVariant=true takes care of. See docs here.

[ephemient]

I thought that's for hmpp which changed defaults with 1.6.20

[mbonnin]

Yea, I was expecting enableCompatibilityMetadataVariant to be more about the metadata than the abi but I'll investigate

[ephemient]

https://kotlinlang.org/docs/components-stability.html still has native klibs as "alpha stability" so I don't think there's a promise of cross-version compatibility

[mbonnin]

That sounds reasonable.

[russhwolf]

There's not a guarantee of backward compatibility for Kotlin/Native but it has been provided experimentally since 1.4. Not sure how that plays into languageVersion though. https://youtrack.jetbrains.com/issue/KT-42293

[mbonnin]

Exactly, the question is whether a newer compiler can generate a binary that uses the older format. JVM can do it with languageVersion but looks like native can't

[mbonnin]

It'd be a useful tool for lib authors to leverage newer tooling (use KGP 1.7 for their own build) but still ship compatible binaries

[russhwolf]

It might be worth asking in that ticket to clarify if that's expected to work or not (and whether it's on the roadmap otherwise)

[mbonnin]

It's not too much of an issue right now as K/N users usually upgrade quite fast but as the ecosystem matures it could be handy

[mbonnin]

I'll ask on that ticket

[russhwolf]

yeah it's not one I think about as much as I probably should, but it'd be nice to get to the point where we have well-defined best practices around that sort of compatibility.

[Jeff Lockhart]

I guess the question would be whether backwards compatibility exists in language versions or would need to be supported first. That might be the main hurdle while things are changing quickly in Kotlin/Native, probably more difficult to support than not.