Is there any reason not to update a public library...

# getting-started

[dave08]

Is there any reason not to update a public library to Kotlin 2.0? Say if a user hasn't updated yet, it'll still work (although they might have to recompile)?

[CLOVIS]

Not any more reasons than for any other Kotlin version.

[dave08]

And what are those (sorry to ask, it's the first library I publicized...)

[dave08]

I've seen some libraries that update to every new versions, whereas others that stay behind for a while... so I'm wondering...

[CLOVIS]

The version you use as a library author is the minimal version you allow your users to use.

There are two main schools:
• Libraries should use old versions of dependencies to allow projects to upgrade themselves while still using newer versions of the libraries.
• Libraries should use the most recent version of their dependencies: if projects want to use the latest version of your work, they should be ready to use the latest version of Kotlin as well.

[CLOVIS]

Since the Kotlin standard library is extremely careful of almost-never breaking things, there's basically no reason to keep old versions, since users can always upgrade it easily.

The tradeoff may be different if you have a dependency on something that breaks all the time, like Spring or Angular.

[Ben Woodworth]

You can get a pretty good overview from here:
https://kotlinlang.org/docs/kotlin-evolution.html

And there's a section on the binary format that has your answer. With Kotlin specifically, 1.9 can likely work with your Kotlin 2.0 library, as long as you only use 1.9 features/stdlib (and there's a languageVersion compiler option that might help you with that)

[...]

• Preferably (but we can't guarantee it), the binary format is mostly forwards compatible with the next language release, but not later ones (in the cases when new features are not used, for example, 1.9 can understand most binaries from 2.0, but not 2.1).

This protocol is designed for comfortable updates as no project can be blocked from updating its dependencies even if it's using a slightly outdated compiler.

[Ben Woodworth]

Also, there's a #library-development channel that might get better sets of eyes on questions like these 😊

[dave08]

Interesting... also nice to know that there's still compatibility one minor version back... so it's kinda in the middle, we do hope that users are at least holding at 1.9.x by now even though they haven't yet upgraded to 2.0 (especially since the IDE support isn't yet finished for 2.0...).

[ephemient]

kotlin-stdlib has at least one release of compatibility but tools that process Kotlin metadata may not be

[dave08]

So if the library doesn't use Kotlin metadata, but the library user does, it might still pose a problem?

[ephemient]

potentially yes, because it'll bring stdlib with newer metadata into the classpath

[dave08]

So it doesn't really help to have that compatibility for library developers... good to know, thanks!

[Ben Woodworth]

For what it's worth, that doesn't stop Jetbrains from consistently using the latest Kotlin version in their first party libraries

I also haven't dealt with metadata so take this with a grain of salt, but this makes it look like metadata processing is also forward compatible to the next Kotlin version going by what this says. For jvm, at least

[ephemient]

kotlinx-metadata-jvm is still working on a stable API so not all tools keep up

[ephemient]

proguard needed a 7.5 release to work with kotlin 2.0 and wasn't available at release for example

[ephemient]

it may be getting better, I haven't noticed any issues with Android Lint this time, but that's been an issue before iirc

[Ben Woodworth]

That's the practical knowledge I was hoping for! Maybe forward compatibility won't be an issue for much longer, now that the metadata library is stable in K2 and things like better metadata dependency constraints are on the horizon. Would certainly be nice to see 😌