What s the best practice around supporting multiple versions kotlinlang #library-development

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

04/02/2021, 10:54 PM

If a project uses your library and Gradle, Gradle will pull

1.4

in the classpath as its a transitive dependency

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

04/02/2021, 11:02 PM

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

04/02/2021, 11:14 PM

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

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.

Usually, the "best" version is the highest

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

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

2 Views

#library-development Join Slack