With latest compose 1.0.3, what's the situation fo...
# compose
f
With latest compose 1.0.3, what's the situation for kotlin 1.5.21 and accompanist v0.18.0? I know I can use 1.5.30 and 0.19.0, but do I need that? The upgrade policy in the 1.0.0 alpha/beta/rc days was that I'd need everything in lockstep, but is that still necessary? I couldn't find any release notes breaking changes, but what's the official way to do this? Side question with AGP 7.1 when it reaches stable and compose 1.1.0 stable when it goes out
j
The Compose Compiler acts as a plugin to the Kotlin compiler. This means that each version of Compose is compatible with a specific version of Kotlin and vice versa, and this will remain true for the foreseeable future. Compose 1.0.3 <==> Kotlin 1.5.31
☝️ 1
f
that was true some time ago because compose was "asking" for changes in kotlin api so it could do things that were not possible before ( if I understand it correctly ). Is that still happening? really curious where to read more about this, since release notes show nothing and reading commits is a bit too hard on a weekly basis.
j
We requested a few changes, but not many, especially in recent times. The vast majority of the breaking API changes are a result of internal refactors within the Kotlin compiler as the compiler improves, not because of changes requested by our team.
f
nice my understanding about this simbiosis is that it's only valid when we're compiling
@Composable
functions. I'd consider it safe to make a library that uses compose 1.0.3 and kotlin 1.5.31 and then bring it into an app that has kotlin 1.5.21 or even let's say 1.5.40 (and let's assume for the moment there's no
@Composable
in that app), because once compose code turns into bytecode everything is compatible with Java 8? I've used projects that worked fine like this. Is there any caveats?
j
Yes, once the code is compiled, the bytecode should work as long as the major version numbers are the same.