What would be the best strategy to keep up with co...

# compiler

[Tóth István Zoltán]

What would be the best strategy to keep up with compiler EAP releases with a compiler plugin?

Let's say the user of the plugin upgrades to Kotlin EAP within a day of its release.

What could I do to help him? How do you guys handle compiler changes with your plugins?

[Youssef Shoaib [MOD]]

Probably best to just keep up with EAPs by developing for them. If an EAP is popular enough, then finalize your current features, make sure tests succeed, etc, and publish a version for it. I've seen plugins explicitly have a version suffix of the Kotlin compiler version

[Tóth István Zoltán]

I mean keeping up with the Kotlin EAP.

[Tóth István Zoltán]

So, a Kotlin EAP arrives, how fast do you release your plugin EAP in relation?

[Youssef Shoaib [MOD]]

You could set up a github action to do that maybe (i.e. build, run tests, and if everything passes, release)

[Youssef Shoaib [MOD]]

Then if it fails, you'll get an email, and you can quickly go in and try to fix things up

[Tóth István Zoltán]

Would that work for iOS target?

[Youssef Shoaib [MOD]]

I believe github actions work for iOS yes. Arrow (which I'm a maintaner of) has github actions for PRs that run tests including iOS (and even watchOS) ones.

[Tóth István Zoltán]

Hm, that's good to know, thank you.

[Youssef Shoaib [MOD]]

Although, depending on your plugin, you may not even need to test on iOS specifically. If it's a general multiplatform plugin, it's probably fine to just test on JVM and maybe JS and Linux. If your plugin does something iOS specific, then definitely test on it of course.
The biggest problem that happens to plugins version-to-version is just ABI changes (methods move around, get deleted etc) or big deprecations (e.g. the changes to Ir parameters that happened recently)

[Tóth István Zoltán]

Hm, the plugin itself is not iOS specific, I'm a bit too deep into multiplatform it seems. :D

[Youssef Shoaib [MOD]]

Then testing on one Native target should probably be good enough. I believe all native targets go through the same process before ultimately diverging in LLVM land, so your code should affect all Native targets the same way (exception being WASM since it's its own target now)