One year or five: this week's releases show how far LTS promises diverge
Three releases this week carry the same word, stability, and mean three different things by it. Read side by side, they are a reminder that "LTS" is a contract whose terms differ by vendor, and that the terms matter more than the label.
Quarkus: a year, and a fast way in. Quarkus 3.40 is the framework's new LTS, supported for 12 months. It is the direct continuation of 3.39, and the team's answer to a short window is tooling: quarkus update is said to upgrade an application from any earlier version, including 2.x. The model assumes teams move often and makes moving cheap. Source: https://quarkus.io/blog/quarkus-3-40-released

Qt: five years, and a regulator in the room. Qt 6.12 is maintained for five years, a new LTS arrives every two years and the lines overlap. The release is pitched around the EU Cyber Resilience Act: the company says it is built for the obligations it expects in December 2027, ships without known exploitable vulnerabilities and comes with response-time guarantees for commercial customers. Here stability means a product can be planned and certified against one version for years. Source: https://www.qt.io/blog/qt-6.12-released
Kotlin: stability marked in the binary. Kotlin 2.5.0 introduces companion blocks and extensions as experimental. Using extensions makes the compiler emit pre-release binaries, so libraries that adopt them may not be consumable as dependencies until the feature is stable. The language enforces its stability promise mechanically, inside the artefact, rather than in a support calendar. Source: https://blog.jetbrains.com/kotlin/2026/09/the-companions-to-come
What to take from it. The questions worth asking of any dependency are the same: how long is the line supported, how many versions can I skip when I move, and what happens if I depend on something marked experimental? Quarkus answers with a short window and a strong migration tool, Qt with a long window and compliance commitments, Kotlin with a compiler-level gate. A team on a 12-month line should rehearse upgrades as routine work; a team relying on a five-year line should check which of the vendor's commitments apply to the open-source edition and which only to commercial customers.