Both latest versions `v1.2.0-alpha01-dev741` and `v1.2.0-alpha01-dev745` compile just fine with Kotl...

# compose-desktop

[Arkadii Ivanov]

Both latest versions v1.2.0-alpha01-dev741 and v1.2.0-alpha01-dev745 compile just fine with Kotlin 1.7.10. Did anything change recently? I thought we would have to wait for a release compatible with Kotlin 1.7.10.

[Landry Norris]

I know 1.7.0 brought the first prototype version of the stable plugin API. I wonder if they rely on that for now.

[Arkadii Ivanov]

Wow that's cool!

[spierce7]

@Landry Norris oh wow… I had no idea. Stable plugin API for compiler plugins you mean? They didn’t talk about this in the release notes did they? I feel like I would have seen something where they were encouraging the public to use it.

[Landry Norris]

Sorry. I meant prototype of the stable API. It’s not stable yet, but this version is supposed to mark them starting the process of stability.

[Landry Norris]

It isn’t supposed to be fully stable until 1.8 or 1.9

[spierce7]

Oh wow. Lol I remember breslev talking about trying to fit in stabilization in 1.5 or 1.6

[spierce7]

Where are you getting that information from?

[Landry Norris]

Looks like it may be K2 only https://youtrack.jetbrains.com/issue/KT-49508/Stabilize-the-K2-Compiler-Plugin-API

[Kirill Grouchnikov]

It probably just happens to be that the compiler didn’t make any “breaking” internal changes between 1.7.0 and 1.7.10

[mcpiroman]

@Landry Norris Not much so. The news are about stable frontend (and analysis?) APIs, so it has little meaning for Compose, as they are mostly about the backend plugin.
Apparently 1.7.10 works because of no breaking change there.

[hfhbd]

They disabled the check: https://github.com/JetBrains/androidx/commit/fd43bd733d7e2a18d27c5fb3dc83541d5fa5e06f

[jim]

That is the jetbrains/multiplatform build. Probably they shouldn't be turning off that check, cc @Igor Demin

[jim]

In our build, the default is to not suppress https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]dx%2Fcompose%2Fcompiler%2Fplugins%2Fkotlin%2FComposePlugin.kt

[jim]

The fact that the Compose Compiler had no changes to support Kotlin 1.7.10 is mostly a result of the fact that the .10 releases are just "urgent cherrypick" releases, they are usually very minor changes. I would expect Compose Compiler which supports Kotlin 1.8.0 to also work with Kotlin 1.8.10 without any changes, but I would not expect it to work with Kotlin 1.7.20 or Kotlin 1.8.20 respectively.

[spierce7]

Isn’t them disabling the compatibility check a bad thing?

[jim]

yes, probably, that's why I cc'd @Igor Demin. They might have a reason, for example, maybe they're building against experimental pre-releases of Kotlin or something for some integration testing.

[Arkadii Ivanov]

How does the plugin decide whether to throw the "incompatible" error or not? In other words, what is the difference between upgrading from 1.7.0 to 1.7.10 and from 1.7.10 to 1.7.20? I always assumed that there is a strict string match logic somewhere, that just compares two versions.

[jim]

We do strict version matching, unless the suppress flag is set as discussed above

[Arkadii Ivanov]

So if you do strict version matching, how you "would expect Compose Compiler which supports Kotlin 1.8.0 to also work with Kotlin 1.8.10 without any changes, but I would not expect it to work with Kotlin 1.7.20 or Kotlin 1.8.20 respectively"? 🙃

[jim]

Well, to work if you suppress. The version check wouldn't know, you'd need to set the flag, but the plugin would likely work, assuming the urgent cherrypicks didn't change any of the APIs. This is unlike a major version bump, where suppressing would likely just give you cryptic errors.

[Arkadii Ivanov]

to work if you suppress

That's the part I was missing, thanks!

This is unlike a major version bump

From the semver perspective, both bumps 1.7.0 -> 1.7.10 and 1.7.10 -> 1.7.20 are just patch changes - so no breaking changes and no new APIs should be present. But looks like Kotlin versioning is a different thing.

[Landry Norris]

Some projects use 1.x as ‘major’ and 1.x.y as ‘minor’ in the 1.0 phase.

[Landry Norris]

I’d imagine when Kotlin 2.0 comes out (whenever that is), it will start using ‘proper’ semver

[jim]

@Arkadii Ivanov Yeah, 1.7.10 and 1.7.20 are both both patch changes from a language perspective. The difference is just in the number of patches (and thus the amount of internal changes). The Kotlin version numbers are correctly semver, but they're tracking the language features (ie. the kotlin language itself), not necessarily the unstable internal implementation details that the Compose Compiler happens to hook into.

[Igor Demin]

Yeah, it was a temporary change. Thanks for bringing this up. We should keep this check enabled by default until Kotlin Compiler API is stabilised.