What’s the best practice around supporting multipl...

# library-development

[Matthew Pope]

What’s the best practice around supporting multiple versions of Kotlin as a library vendor? I have a library that was written with Kotlin 1.3, and it has consumers on both 1.3 and 1.4. Can I safely upgrade my own library to use Kotlin 1.4 if I set -language-version and -api-version compiler options to 1.3? (Do I need both or just one?)

[mbonnin]

If a project uses your library and Gradle, Gradle will pull 1.4 in the classpath as its a transitive dependency

[mbonnin]

One of the places where it has been problematic is Gradle plugins because Gradle forces 1.3 in the runtime classpath but for the vast majority of the cases, there shouldn't be a problem upgrading Kotlin to 1.4 in the consumer project

[Matthew Pope]

Transitive dependency shouldn’t be a problem if I specify a range of versions, right? If I specify [1.3, 1.5) , wouldn’t that allow me to build with 1.4 while allowing consumers to choose between 1.3 and 1.4?

Or are you saying that Gradle plugins bring in unavoidable transitive dependencies?

[mbonnin]

Your lib can only depend on one version of the stdlib so [1.3, 1.5) while building the lib doesn't really make sense. Usually I try to avoid ranges as it gives more predictive results

[mbonnin]

What version of your lib depends on will be written in the pom file.
If an app consumes your lib, Gradle will read this pom file for all libs and resolve the best version.

[mbonnin]

Usually, the "best" version is the highest

[mbonnin]

https://docs.gradle.org/current/userguide/dependency_management.html#sub:resolution-strategy

[mbonnin]

Overall, unless you have a proven reason to, I wouldn't worry too much about Kotlin 1.3 consumers as they usually can upgrade to 1.4 easily