Are there any plans to speed up providing support ...

# compose

[eygraber]

Are there any plans to speed up providing support for new Kotlin versions? It's been weeks since 1.8 was released. KSP supported it almost immediately, and JB Compose released support for it today.

Based on something a JB engineer told me, stable compiler plugin APIs are at least 1.5 years away, which seems like a very long time to spend trailing the newest versions of Kotlin.

I know there are dev builds available that support it, but I wouldn't use those in production.

[Landry Norris]

There was a compiler pre-release a week or so ago.

[eygraber]

I mentioned that. Aren't they not supposed to be used in production?

[Landry Norris]

The compose compiler is safer to use as a pre-release, from my understanding.

[jw]

But that begs the question then why can't it just be the actual release?

[Tolriq]

The reason you always invoke about the monorepo ? 🙂 Seems they just merged the changes and Kolin 1.8 had impact on other jetpack libs.

[jw]

Yes the changes were ready to be merged the day of the 1.8 release and it took nearly two weeks to update the unrelated libraries which live in the same repo. It means we have to wait 3 weeks to get a release that was otherwise ready the same day.

[Landry Norris]

They also had a set of releases yesterday. I bet they want to not have a ‘formal’ release right before the rest.

[jw]

The releases are scheduled and were branched a week ago. It's a pretty standard train system. You either make it or you catch the next one. There's no human deciding such things.

[eygraber]

And the chances of Compose being split out of the monorepo are approaching zero, or are zero (not expecting anyone to have the answer to this; just semi ranting)?

[jw]

Hard to know. In general, Google as a collective has a lot of sunk cost fallacy and the belief that you can keep writing more code to solve the next problem. One of the reason they're in the place they are now is they kept writing code to solve infrastructure problems of the monorepo over and over and now there's so much it probably feels like they can't do without it.

[jw]

Except unlike Google's actual real monorepo, AndroidX has nowhere near the required amount of people to build the infrastructure necessary to accommodate their growing needs.

[eygraber]

So this isn't necessarily the same underlying issue as e.g. the Compose UI vs Compose naming issue