A modern programming language that makes developers happier.

kotlinlang

When Compose 1.2.0 reaches stable , will it target 1.6.21 or 1.7.0 of the Kotlin Compiler

Kotlin 1.7.0 support will be in Compose 1.3.0-beta01 <https://android-review.googlesource.com/c/platform/frameworks/support/+/2133474>

Does that mean that the 1.3.0 alphas will not support 1.7.0?

The current plan (no promises, subject to change, yada yada) is that Compose 1.2.0 will target the Kotlin Compiler 1.7.0.

It is worth noting that the Compose Compiler versions are not tightly coupled with the versions of any other Compose libraries.  For example, you can use beta builds of the compose compiler with stable builds of the various Compose libraries, etc.

It is also worth noting that you can grab a pre-release of the Compose Compiler which already supports Kotlin 1.7.0 located at: <https://androidx.dev/storage/compose-compiler/repository>

Jim, wouldn't make sense split versioning of Compiler and rest of Compose? Similarly, Compose Material 3 has a different versioning.

Btw how is that independence of :compiler module actually achieved, when it is strongly coupled with :runtime (and :tooling?)? Is it just expected that for a while there will be no changes that need to be synchronized across those two modules?

Thanks for the infornation people. I didnt realize that  the compose compiler was that loosely couple to the other dependency. Thought the versions had to be in sync

newer compose compiler is meant to work fine with older compose library. I'm not sure what the guarantees are the other way around, though

<@UDS12QTHB> Yes, we intend to do this probably in the next few days.  It has already effectively been true that the versions were decoupled but "coincidentally" had the same version number.  We intend to officially change this and have compose compiler versions move independently very shortly.

<@UJQB4DJF7> The other way around is also mostly guaranteed, by virtue of the way libraries work.  Suppose WidgetA is compiled with old compiler, and WidgetB requires new runtime, it needs to be true that WidgetA is compatible with the newer runtime, which is effectively the same as saying "there can be no breaking changes in the runtime" which is effectively the same as saying "older compiler needs to be able to work with new runtime".  So the compatibility guarantees go both directions.

When do we expect to hit a point where the kotlin compiler plugin API is stable so that the compose compiler is not longer tied to a specific kotlin version?

<@U5MF219BP> Nothing official, but from me following (and contributing to) the development of kotlin, I'd say not anytime soon.
But that should not be a big deal now, with decoupled compiler I imagine it to be much simpler to prepare and release it for a new kotlin version quickly, even on day one.

<@U6158UG1Z> Maybe it's then worth adopting a versioning for the compiler plugin similar to that of KSP, e.g. 1.7.0-1.2.0-rc2.
Also, will such compatibility guarantee last forever, or is it expected to have a breaking change between compose `compiler`-`the rest`  at some point? Maybe even between major compose versions? Because I imagine it will be necessary, e.g. for performance improvements.

Isn’t the goal to have a stable plugin SDK for 1.9? That would place the release around this time next year.

<https://twitter.com/JimSproch/status/1542193552326680577>