Hello, hope everyone is doing good. Does Kotlin has a Long Term Support (LTS) version like Java ? I ...

# server

[Loïc Lamarque]

Hello, hope everyone is doing good.
Does Kotlin has a Long Term Support (LTS) version like Java ?
I can't find any resource on this topic...

[Jacob]

https://kotlinlang.org/docs/kotlin-evolution.html is the best information I can find on the strategy

[Jacob]

also see https://blog.jetbrains.com/kotlin/2023/02/k2-kotlin-2-0/

[CLOVIS]

It wouldn't really make sense.

The concept of LTS only really has meaning for something you use in production. In the Java ecosystem, it's the JVM: if a critical issue is found, it needs to be fixed even for users who cannot upgrade to another major version.

The Java language itself doesn't really have a concept of LTS. The language and the compiler aren't used in production, if a serious issue is found you can just upgrade it while targeting the old bytecode level.

Kotlin doesn't ship its own runtime (it either uses the JVM, Node, or just runs by itself for Kotlin Native), it's just the compiler. Since nothing from the Kotlin team is deployed in production, there's nothing they could offer support for.

[Klitos Kyriacou]

I thought it was the JRE (which includes the Java API library) that was in LTS, and not just the JVM. If a serious vulnerability was found in, let's say, a java.util.Map method of Java 11, they would back-fix the Java 11 version of it as it's still in LTS. In that respect, the Kotlin stdlib is also employed on production servers.

[CLOVIS]

If that happened in the Kotlin ecosystem, you could just replace the standard library in the JAR to a newest one.

But I assume most people would prefer upgrading Kotlin (compiler + stdlib etc) and redeploy

[Loïc Lamarque]

Thank you @Jacob for your ressources. It's interesting to see how the Kotlin team approaches the evolution of the language, even for Kotlin 2.0 where they don't follow programming languages conventions but software programs ones...

I understand your point @CLOVIS. Thank you for your help on that.

These discussions give me also another important question: if there is no LTS version for Kotlin, when should we upgrade it in a library?
My question is not about applications because not having dependents is easier than having Kotlin consumers using your library: upgrading to the latest Kotlin version when available is possible in this context.
But for a library, I don't know what's the good practice...

[CLOVIS]

The Kotlin version you define when writing a library is the lowest Kotlin version your users can use (safely). If they are worried about security concerns, they can always use a more recent version*.

So, in practice, as a library author, there are two schools of thought:
• either you decide that a user who wants to use an old version of Kotlin should use an old version of your library too,
• either you decide that you want your users to be able to use old versions of Kotlin with the latest version of your library.

In the first case, you always target the latest stable Kotlin version. In the second case, you decide on a time offset (e.g. 2 years), and target the Kotlin version from that long ago, so all users who are less than 2 years out of date on Kotlin can use the latest version of your library.

Of course, if you do that, it means you can't use the new shiny things in your library code. So it's really a choice that you have to make.

*as long as you don't OptIn to experimental stuff

[CLOVIS]

Personally, I'm in the first category: I believe that if users want the latest from me, it's reasonable to expect them to want the latest from the Kotlin team too.

[Loïc Lamarque]

Interesting @CLOVIS.
The second option also improves the compatibility of the library with wider range of applications using an older version of Kotlin (a not deprecated one according to the languageVersion compiler option). So it is also a choice between using the new shiny things and striving for security...

[CLOVIS]

I don't agree with the word ‘security’ here. It's “shiny new things” vs “pay the cost of supporting multiple versions at once because your users don't want to upgrade”.

[Loïc Lamarque]

That's true @CLOVIS. Maybe user convenience is more accurate, but I understand your point.