Hey folks! Our Kotlin team has been discussing whe...

# server

[Anton Yalyshev [JB]]

Hey folks!
Our Kotlin team has been discussing whether Kotlin should introduce a concept of LTS versions — and, more importantly, why. Does our server-side community actually experience issues that LTS could solve? Or does the lack of LTS discourage Java users from switching to Kotlin?

Please share your thoughts, especially if you’ve run into problems that wouldn’t have occurred if Kotlin had LTS releases.

Bonus question: What should the scope of an LTS include — just the compiler and standard library, or also compiler plugins, or + core libraries like coroutines, or + the Kotlin Gradle plugin?

[Bartosz Markowski]

Kotlin version is in spring boot bom and from my experience I would say that this is safest way to use kotlin with spring boot

[gpopides]

The java community has already a very big misconception of what LTS means. The JDK for example has not non paid LTS versions but this does not prevent them staying on older JDK versions because they think its an LTS.

Whats the reason behind these thoughts?

[ross_a]

My company has been using Kotlin fairly heavily since 1.0 and I do not think we have had very many issues at all regarding upgrading - we tend to be on the most recent version, and ahead of Spring typically. We had one minor issue with 2.0 which was quickly resolved in the next patch.

As mentioned before, the version provided by Spring Boot works fairly well as an unofficial LTS for those who do not want to particularly think about it.

The biggest compatibility issues we have had have come from custom plugins and Gradle's bundled versions which I think are mostly resolved now.

Generally I think the current approach with OptIn and @Experimental work well to avoid the need for LTS, since outside of changes such as context receivers (which are expected) we haven't experienced backwards compatibility issues.

If there was a need for changes to stable APIs or language features then I think it would be worth considering.

We solely use the JVM though, so that may colour my view.

[Anton Yalyshev [JB]]

Whats the reason behind these thoughts?

Doesn’t OpenJDK distribution get patches with security fixes? As far as I see it’s available for everyone.

The main reasons are:
• To give predictability for enterprise teams, that they will have supported version of software, with no needs of frequent updates. Supported means getting patches with critical/CVE fixes. Some regulations explicitly require “supported” versions of used software components.
• LTS versions make a kind of alignment among ecosystem components. So if you use LTS, you have a decent ranges of compatible versions of Gradle, Spring, SAST tools, maybe even KSP. It reduces risks of cases when after updating of one component you need to update many others.

[Robert Jaros]

With Java "long" means 8 years and it is long. I can't believe JB can afford supporting one Kotlin line for 8 years. AFAIK 8 years ago Kotlin 1.1 was released.

[jw]

The JDK vendor's LTS benefits the VM and runtime libraries and Kotlin has neither.

I think Kotlin and KGP should do a better job of encouraging users to set low API, language, and core library versions, but still compile with the latest Kotlin always. The same way you should be using Java 25 to compile but -release 11 to target older JDKs, not use Java 11 to target 11.

[Anton Yalyshev [JB]]

The JDK vendor’s LTS benefits the VM and runtime libraries and Kotlin has neither.

@jw Aren’t kotlin-stdlib, kotlin-reflect and kotlinx.* runtime libraries, in that sense?

[jw]

No, the JDK's runtime is shipped alongside the VM. You can never fix a bug in the JDK runtime by redeploying your application. Kotlin is part of your application, not the runtime.

[gpopides]

Also i would like to note that in the JVM side (i dont have knowledge about multiplatform or android) the JDK team suggests to use the latest version which changes every 6 months.

Its already a problem because JDK 25 was released on 21th of October but we still cannot use it because we are waiting for kotlin 2.3

If you were to use LTS releases you would have to keep them on the same pace as the JDK ones as mentioned above or am i missing something?

also,
> LTS versions make a kind of alignment among ecosystem components. So if you use LTS, you have a decent ranges of compatible versions of Gradle, Spring, SAST tools, maybe even KSP. It reduces risks of cases when after updating of one component you need to update many others.
i dont have a lot of context with this as we are trying to use the latest as often as possible but i have seen in the JVM world that updating the jvm version from 21 -> 22 -> 23 etc is painless already

[jw]

What prevents you from using JDK 25? I'm using JDK 25 both for compilation locally and in deployments with Kotlin 2.2.21 without problem.

[jw]

Once you get over the 8->9 hump, I agree the best LTS is just the latest version of Java.

[Rey (Kingg22)]

I don’t think Kotlin needs an LTS release model — in fact, adopting one could slow the language down more than it would help. Kotlin already solves most of the problems that LTS versions try to address, but with more modern and flexible mechanisms.

1. We risk repeating Java’s stagnation pattern.
The “LTS mindset” is what kept a huge portion of the Java ecosystem stuck on Java 8 for years. Companies often cling to the LTS label as an excuse not to upgrade, even when newer versions are stable and compatible. Kotlin has so far avoided that cultural problem — introducing LTS could encourage it.


2. Kotlin already has strong tooling for controlled stability.
Experimental features are opt-in (similar to JDK previews but more granular), and language/API version selectors allow teams to control behavior and upgrade progressively. Combined with compiler arguments, organizations can adopt features incrementally without freezing themselves on an old major version.

Existing limitations do exist (e.g., only Kotlin + kotlinx follow API versioning consistently, and third-party Gradle/plugins can force upgrades), but those are solvable without introducing LTS. Better ecosystem support would be more productive than maintaining legacy releases.

3. Maintenance overhead slows evolution.
Maintaining LTS branches requires time, testing, backports, and security patches. Kotlin’s evolution has been healthy precisely because releases are incremental, documented, and relatively low-risk. LTS introduces technical/organizational inertia that could hold back improvements — especially now with K2 and compiler modernization.

4. Breaking changes in Kotlin are rare.
Upgrading Kotlin is usually safe unless you're using experimental features or deep compiler plugins. The upgrade path between versions is typically smooth, well documented, and supported by tooling warnings. Kotlin is already far more stable by default than languages that need LTS to provide certainty.

5. Real-world evidence suggests LTS isn’t necessary.
A good example is Spring. Before Spring Boot 4 aligned with Kotlin 2.2, Spring apps could run on newer Kotlin versions even when older versions were "recommended." K2 was one of the biggest compiler shifts in years, but many Spring projects upgraded without major issues. If a massive ecosystem like Spring can operate without LTS constraints for so long, that says something.

6. Better alternative: strengthen version compatibility policies instead of LTS.
If the goal is "enterprise stability," there are more modern paths:
• Encourage languageVersion and apiVersion as first-class stability tools.
• Promote BOM and version alignment strategies across ecosystem libs.
• Improve compatibility constraints for plugins, Gradle integrations, and compiler extensions.
• Emit clearer warnings when transitive dependencies force Kotlin upgrades (similar to Gradle’s version constraints & conflict resolution).
• A compatibility matrix or certification program would give companies confidence without fragmenting the release model.
TLDR, Kotlin doesn’t need LTS to be stable. What it needs is continued investment in tooling, compatibility policies, and ecosystem alignment. LTS could freeze progress, encourage stagnation, and introduce fragmentation — while adding little value over mechanisms Kotlin already has.

[wakingrufus]

I don't think LTS is needed, and the points above I generally agree with. I do think it would be nice to have some kind of timeline of critical fixes to older versions. such as:

critical fixes will be delivered to the current minor/language release, and 1 previous, for 6 months
critical fixes will be delivered to the current major release, and 1 previous, for 1 year

so if 2.1.21 is out, then 2.2.0 is released, then 2.2.20 is released, and 2.2.0 is still < 6 months old and 2.3.0 is still not out, and a critical issue is found, then a 2.2.21 AND 2.1.22 will be created. also if its been < 1 year since 2.0.0 was released, then the latest 1.x will also get a new patch version.
This would help those of us who build internal tooling to plan out when to support new versions, what timeline we can reasonably give our own customers for performing migrations, and when we can reasonably drop support for older versions. The current "as soon as a new release is out, all other versions are immediately EOL" is not really feasible in a large organization.
TBH, right now this is mostly driven by what KGP supports, but KGP supports much older versions than what is considered "supported" by the kotlin team, so there is a mismatch there. a more defined support schedule from the kotlin team would make it more justifiable to promote upgrades before waiting for KGP to drop support

[Anurag Soni]

Speaking for myself (although using Kotlin at work for server-side things for a couple of years now). Not sure we'll benefit much (at all?) from a LTS release, we like to stick with the current stable JDK releases so personally its more advantageous to have kotlin working well with current stable JDK releases as opposed to sticking to a single "LTS".

What might actually be more helpful is something tooling that can help migrate to adapt to any potential breaking changes (similar to https://scalacenter.github.io/scalafix/). I find it much easier/simpler to keep with small incremental updates rather than stick to an older "LTS" and have one-off big-bang updates where a LOT has changed.

[Mervyn McCreight]

I don't think LTS is necessary. Updating kotlin so far was never a big issue, as long as it stays like this it's okay to just always try to be on latest IMO.

[Kuyho Chung]

Ive been using Kotlin with Spring Boot for about three years and never thought of the necessity of LTS versions. Pretty much because moving to newer release of Kotlin was never a big deal.

[Peter Urs]

Last week we ran the KotlinDevDay conference. At the end, I hosted a panel discussion with well-known Kotlin VIPs from JetBrains (like @mikhail.zarechenskiy, @Alejandro Serrano.Mena ) To make it more interactive we had a Kahoot poll, where - upon JetBrains request - we also asked the audience about LTS. This is the outcome:


13 out of 91 answered they would like LTS. So it seems there is a bit of interest.

[spand]

Maybe impossible but Jake Wharton is pointing to the real issue. We have been using Kotlin since before 1.0 and by far the biggest issues are the fact that you cannot bump anything without bumping everything in lockstep.
Need a new kotlin ? Then you need to bump gradle, ktor, exposed. kotlin-react etc.
It is made worse by the fact that many parts of the kotlin infrastructure and frameworks maybe never really got out of beta quality so getting a good version of the everything that works together has been pretty rough. The worst example was probably the kotlin-gradle-frontend that bare got out of alpha quality.

So from my point of view, to second Jake, push the ecosystem (not just Jetbrains) to wider compatibility and additionally finish the many issues left in the ecosystem so old versions are actually working. ie. spend a year just fixing bugs. (ie. how can bog standard stuff like this be broken for 5 years https://youtrack.jetbrains.com/issue/KTIJ-16582)

[Bartosz Markowski]

But are we talking about language itself? Or tools around it. Java LTS is for jvm. What would be in kotlin lts? Kotlin is language. Maybe LTS version of ktor?

[Anton Yalyshev [JB]]

Kotlin is not only a language but also a set of core libraries, so an LTS model for Kotlin is closer to the LTS policies of libraries and frameworks (e.g., Spring, Hibernate, Log4j). From our YouTrack we see that the stdlib sometimes have security issues. It might therefore make sense to introduce a “support window” of about 18 months for it, so an enterprise project can freeze its stack while knowing that Kotlin-related security risks are covered.

This policy could also help with compliance checks — there would be fewer questions about unsupported software.
It would not, however, solve ecosystem alignment and compatibility issues. That’s a separate track which, as many good suggestions above highlight, has alternatives to an LTS model.

[Yuri Geronimus]

Impact is situational from my point of view.

For instance, to enterprise/regulatory teams, every Kotlin upgrade is costly as it activates deployment freezes, full regression cycles, and compliance testing, and during that window delivery freezes, negatively impacting TTM. In business case / NPV model, that upgrade freeze is very negative due to real costs and value delays. I think you don't hear a lot of these voices because of lack of enterprise employees presence in Kotlin community (it is a hypothesis).

Overall, “LTS” i believe is mostly applicable to enterprise customers. This “LTS” though is probably less about the programming language itself, and more about stable and consistent support and maintenance for the full toolchain and ecosystem, which includes things like K2 maturity and Kotlin Gradle Plugin Stability and Compatibility, compiler plugins.

Rather than treating LTS as a feature in of itself, it seems more valuable to do enterprise customer development end to end, engaging with regulated and large organizations to understand, validate, and base the policy on what support window, security updates, interoperability, and change control are required to meet those needs. Integration with enterprise tools looks like Sonar, etc... Even official specialist certification can be a very big plus for enterprise...

[Yuri Geronimus]

We must understand that once the security update time frame is up, Enterprise clients cannot continue to remain on the system. Updates must be set to be manage months before the timeline expires.

If your current time frame from the release to the expiry of security updates is 6–7 months. Then that means enterprises must migrate every last half of the year. This ultimately leads to a 1–2 month loss in TTM every year and migration cost each time.

IMO, this is something that we should fix... it can break whole idea of using Kotlin in server side for enterprise customers (but only for them)...

But because of Kotlin is not OS, system software, maybe they can apply...

In the end I want to say again: maybe we need to make defining of enterprise customer needs in general, not only about LTS.


(This is, of course, the case as long as I am not mistaken in the table provided at https://endoflife.date/kotlin – I beg your pardon if I am mistaken)

[Jakub Gwóźdź]

I'm happy with current setup of releases (if it isn't -beta nor -rc, and I do not use opt-it/experimental, I consider the feature stable and "LTS"-ish), but what I miss, is a lack of clear compatibility guide (say: kotlin x.y.z works well with java nn, ktor a.b.c, kotlinx-serialization d.e.f, gradle g.h and so on), so I can stay on newest versions where possible without worrying about losing some compatibility or getting unwanted build warnings)