Hi :wave: Quick question: When developing a libra...

# getting-started

[Lukas K-G]

Hi 👋 Quick question: When developing a library (in my case an Android library), how do I know with which other Kotlin versions it will be compatible? E.g. when I am using latest 1.7, will a consumer of my library that uses Kotlin 1.5 have issues?

[Casey Brooks]

Kotlin follows Semantic Versioning, so no, you cannot expect compatibility with 1.5 if you’re developing against 1.7. This is because 1.7 is a minor version bump which may have new features that did not exist in 1.5. Thus, it’s likely users running 1.5 will encounter things like ClassNotFoundException.

However, the reverse is expected to work fine. If you compile your library against 1.5, users running 1.7 should be able to use it, since there should not be any breaking changes in a minor version bump. Nothing that previously compiled in 1.5 will suddenly be changed or removed until Kotlin hits 2.0

[Casey Brooks]

Also, this strict semantic versioning only applied to the Kotlin stdlib. Kotlinx libraries and other open source libraries may have different requirements/breaking changes, which will likely negatively impact compatibility across minor versions of Kotlin

[Landry Norris]

Kotlin/Native doesn’t quite follow this. For example, freezing was deprecated in 1.7, and will likely be removed at some point. They also change the ABI occasionally.

[Casey Brooks]

Deprecation is not a breaking change. those ABIs still exist and code will continue to compile and run when using those APIs

[Casey Brooks]

But as a general rule, compile your library against the lowest version of Kotlin you expect it to be used on, but try to keep it as recent as possible. Prefer updating your library to support later versions of Kotlin, rather than assuming compatibility with later versions

[Gleb Minaev]

There is such fragment from Kotlin specs:

Kotlin Language Specification is still in progress and has experimental stability level, meaning no compatibility should be expected between even incremental releases, any functionality can be added, removed or changed without warning.

[Landry Norris]

I’d check this site for details. Anything that isn’t marked as stable doesn’t guarantee compatibility.

[Landry Norris]

I remember that they changed the K/N ABI such that it was incompatible a few versions back (either 1.5 or 1.6), which is technically fine, since it’s not stable yet. There’s a youtrack for stabilizing klibs as well.

[Lukas K-G]

Thanks, this is very helpful already. Looks like I will not be able to have all the shiny new language features in my library if I want to provide decent backwards compatibility.

[Landry Norris]

I’d imagine most people will be on newer Kotlin versions. You should be fine with supporting 1.6+ unless you have data saying otherwise.

[Landry Norris]

For Android specifically, I’d expect compatibility to be better, but on K/N (on iOS for example), I find it best to match the versions as close as possible to what you expect users to be using.

[Casey Brooks]

The Kotlin community usually does a good job of keeping libraries up to date. Whenever I make a new library, I usually default to targeting the latest version of Kotlin that all the library’s dependencies support. It’s typically close to the latest version of Kotlin available, but not always the latest. And yes, as Landry notes, JVM/Android libraries typically have better compatibility than those with iOS/JS targets.

For example, if I were to create a new library right now, I would probably target 1.7.21, since it’s been available for a little while now, and most things I would need for it should support 1.7.21 by now. But if it included anything related to Compose, I would have to drop down to 1.7.10, since it’s known that Compose/Web does not work with 1.7.21 yet

[Landry Norris]

since it's known that Compose/Web does not work with 1.7.21 yet

I believe they actually fixed support for 1.7.20 on web a couple of days ago with 1.2.1

[Casey Brooks]

Oh hey, I must have missed that! Thanks for the heads-up there, now I can go update my libraries 😂

[Joffrey]

you cannot expect compatibility with 1.5 if you’re developing against 1.7

While this is true, I wonder how that plays out with the stdlib dependency resolution. Usually the build system will resolve dependency conflicts by using the most recent version unless strict rules are enforced to override this behaviour.

This means that consumers of a library that depends on the stdlib 1.7.21 will likely use that stdlib, even if they're compiling with Kotlin 1.5. But maybe the Kotlin gradle plugin actually sets strict rules to the stdlib it automatically adds? Not sure

[Lukas K-G]

I found an interesting blog post that fits this topic in case someone else stumbles upon this in the future: https://blog.mbonnin.net/kotlin-compatibility-quicksheet