I'm trying to decide which kotlin-stdlib version I...
# library-development
a
I'm trying to decide which kotlin-stdlib version I should be using in my libraries. Pretty much all the libraries I use (http4k, moshi, okhttp, forkhandles, with the unsurprising exception of jackson-module-kotlin), use the latest kotlin-stdlib version at the time of their release. I've been doing the same, but I just recently had a user complain they couldn't use my library because they were still on Kotlin 1.6. The only time I've ever had a blocker to upgrading is when Kotlin 1.5 broke my usage of Javalin's OpenApi annotations. I'm not sure if I should be trying to target some minimum stdlib version, or if it's on the user to stay up to date. What does everyone else do? 🤷
👀 2
m
I like being conservative for users. Unless there's a strong reason (sealed interfaces were the last one IIRC), I use the oldest I can. You can use
kotlin.stdlib.default.dependency=false
and
apiVersion
/`languageVersion`
f
Isn't K binary-compatible with old versions? Why can't a user with 1.6 use the 1.9 library?
m
Gradle comes to mind 😅
Also the 1.6 compiler cannot read the 1.8 metadata
So it works fine at runtime.... if you manage to compile your project in the first place
f
Makes sense. Then why would some user of the library use version 1.6 instead of 1.9? 🤔 What's the advantage there?
m
Just because they don't have bandwidth and/or knowledge to migrate to 1.9 I guess
a
Interesting. Will
kotlin.stdlib.default.dependency=false
either: 1. require users to bring in their own stdlib, possibly causing compatibility issues if theirs is too old 2. inline any stdlib function calls into my class files, eliminating the need for the user to have the stdlib at all 3. some other effect?
m
3. it means you control the stdlib version that your lib depends on
This way you can use latest KGP but still ship libraries that are compatible with a wide range of consumers
a
Interesting. I'll look into it. Thanks for the tip!