Status Update
No update yet.
Comments
al...@google.com
Triage notes: A library compiled against tip-of-tree with the pausable composition flag enabled would not be able to target 1.7 at run time, but that's going to be on by default at some point. We need to know whether this team is able to compile against a pinned version, e.g. using Gradle, to generate their release. If they can then this is a P3. If they can't, we need to know whether they can target 1.8 stable at run time (e.g. in their POM).
al...@google.com
Lowering to P3. The team that raised this isn't using Compose yet and by the time they are, they'll be able to use 1.8.
al...@google.com
Triage notes: We do have an existing proposal for @Since for Kotlin, we'd probably want to migrate to that once it's ready. Alternatively, we don't have to annotate methods directly -- we could just special-case them in the compiler. Deserves a one-pager / short design doc to pin down a solution. Still P3 until we start introducing more APIs.
Description
In cases where an SDK is being developed in a monorepo and shipped externally, it would be useful to have a way to restrict the Compose Compiler's code generation to target a specific version of the Compose Runtime -- similar to how the Kotlin Compiler can target an earlier language version and thus work with an older
kotlin-stdlibversion at runtime.Looping in discussion from chat, this may require tagging
@InternalCompilerApi-annotated APIs with an additional@Sincebinary-retention annotation.