Hello, I saw a Tweet from Jake Wharton saying that...

# ksp

[Justin Tullgren]

Hello, I saw a Tweet from Jake Wharton saying that KSP is released within hours after a kotlin release. I was wondering if anyone had blog posts or thoughts that could share about how thats accomplished? We manage an Android SDK that could benefit from turn around like that for kotlin updates. Thanks!

[Justin Tullgren]

To add context we have tests and automation, i am just curious how upgrading the kotlin stdlib and couroutines lib doesn't force checking for runtime issues on transitive libs that get built using the newer version when gradle brings the version up

[Paul Woitaschek]

Just don't join the androidx mono repo, then you are not tied to gigantic release cycles. That was his argument

[Justin Tullgren]

ah.

[Justin Tullgren]

ok thought maybe there was some other insight to gather but guess not. Thanks!

[Paul Woitaschek]

And the reason why KSP was ready is that it prepares versions with the release candidates already

[Paul Woitaschek]

So if you want to release quickly after a release, prepare for these RC changes if they affect you.

[Justin Tullgren]

okay that is something we don't do. Hard with a small team to understand if we hit an RC bug or our own code bug but good thought.

[Paul Woitaschek]

But usually if you are in the library your SDK will certainly work with all newer kotlin Version out of the box. Except you fish into the internals ofc

[Justin Tullgren]

ya we don't do that

[Paul Woitaschek]

This whole topic is really only relevant if you are connecting to the compiler like compose and KSP do

[Paul Woitaschek]

But at some point even the compiler plugin Api will stabilize

[Justin Tullgren]

k good to know. can't get much context out of tweets sometimes. Thanks for the replies!

[Paul Woitaschek]

🤗 welcome

[Ting-Yuan Huang]

In addition to being a smaller project, one thing that KSP does to earn more response time for breaking changes from Kotlin compiler is tracking Kotlin's master branch besides the most recent stable release. The downside is more branches (we got 3: current release, next release, and main) to maintain. If you have a strong dependency into a library, like KSP to Kotlin, this might be worth considering.

[Justin Tullgren]

ya unfortunately small team with big roadmap so thats hard to do

[Jiaxiang]

RC bug is uncommon, bumping to RC in time should help in my opinion.

[gildor]

Have you ever had case when you had to update after Kotlin release?
For libraries which do not use internal APIs it should be seamless, Kotlin is backward compatible, nothing pushing you to update Kotlin, you can use whatever stdlib/Kotlin version was available
You should update only if yourself want to get some new Kotlin features for your own development
I would even say that for SDKs it would be nice to not rush too much or at least do not use the most recent API levels of Kotlin right after major release, otherwise it would require your clients to also update it

For KSP and Compose it’s important because of compiler plugins to support new version of Kotlin, otherwise they will not work.

[gildor]

Though, it’s nice to try RC/Milestones to make sure that there are no regression which affect your code, but I wouldn’t say that it’s so important for small teams and for most libraries, it can be important for big applications, especially ones which use compiler plugins such as Compose and KSP

[ephemient]

plugins do need to follow the compiler closely, but I would say that a library should target the minimum Kotlin version reasonably possible, to be usable by the most consumers

[Justin Tullgren]

No we have never had a case of needing to update right away. My reason for asking is just that we are a small team and constantly looking for how to deliver faster, especially if a customer (we are a paid sdk), needs something asap.

[Justin Tullgren]

My original question was just trying understand the magic of how KSP moved quickly and to glean anything useful.

[Paul Woitaschek]

@ephemient
It does not target a kotlin Version but a language level which can be set independently.