https://kotlinlang.org logo
Join Slack
Powered by
The time has come: since the introduction of the b...
# github-workflows-kt
p
The time has come: since the introduction of the bindings server, we're observing the first minor version bump for Kotlin. This PR: fix(deps): update kotlin monorepo to v2.2.0, once deployed, is going to affect how bindings are compiled on the fly, and break clients that still use Kotlin 2.0.x to compile their workflows. If you use workers provided by GitHub, you have no need to worry. However, if you use your own runners and control Kotlin's version yourself, you'll have to update it to at least 2.1.0. Ideally we'd publish it in a non-breaking way, as v2 for server routes, however it would require making v1 and v2 routes use different Kotlin compiler version which is not yet implemented (I have no experience with such setup).
v
Why breaking clients? Have you considered supporting the older clients for a while?
p
Why breaking clients?
for clarity, are you asking why this change breaks the clients, or why I decided to introduce the change now?
v
I wonder why does it break clients
p
ah ok - it's about Kotlin metadata attached to a JAR. If you think of Kotlin Script representing the GitHub workflows as consumers, and bindings provided by the bindings server, they are independent in terms of Kotlin compiler. There's a certain allowed version difference between the consumer and consumee Kotlin compiler. This error will show it best:
Copy code
.github/workflows/test-script-consuming-jit-bindings-older-kotlin.main.kts:34:9: error: class 'io.github.typesafegithub.workflows.actions.actions.Checkout' was compiled with an incompatible version of Kotlin. The actual metadata version is 2.2.0, but the compiler version 2.0.0 can read versions up to 2.1.0.
v
Kotlin supports targeting the older version, so have you considered targeting say Kotlin 1.8, so 1.8+ clients can work with that code?
p
that's true, we could do it, but I'm wondering if it really makes sense, that is: if in practice, we have clients with older Kotlin on the runners. Runners are a fairly isolated component so I'd presume it's easy to upgrade
that being said, if I get any complaints after the next server deployment (Sunday) that folks got broken workflows by this change and cannot easily update their Kotlin, I'll consider what you propose!
v
If you force everybody to upgrade, then you literally cut your userbase. They won’t complain, but they would just stop using the software
p
yes, that's the worst case scenario... maybe indeed we should keep compatibility which would buy us time to figure out how to roll out such upgrades in a separate server routes
thanks, I'll play with this
v
Of course, if the newer version yields some features that can’t easily be implemented (e.g. some fancy new compiler API FIR/IR/whatevIR) with an older version, then it might indeed be fine to have a breaking change. If you do not rely on the new features, it would be great if you could keep N-2 (or whatever) compatibility to give the users time to upgrade their runtime versions.
p
the bindings are very simple and don't use any fancy features (for now), so indeed it's an argument for preserving compatibility
❤️ 1
v
Kotlin 2.0 released ~1 year ago. Having 
2.0
requirement might be too strict. By the way, which JVM release do you target? (== what is your 
-Xjdk-release
option?)
p
Having 
2.0
requirement might be too strict.
do you mean we should go with even lower version? I'm not sure if it's possible
By the way, which JVM release do you target? (== what is your 
-Xjdk-release
option?)
I think it's 17. For the library, it's 11. I haven't really thought about the bindings' JDK release version, and I should
v
Java 17 released in Sep 2021. In other words, you still allow clients to use 4-year-old JVM (which is not bad) while you “force” them to upgrade Kotlin every year. It does not look consistent.
AFAIK, 
jvmTarget
is not enough, and you need to add 
-Xjdk-release
so the compiler uses the proper APIs. At the same time, I see you use toolchain=11 which is not that good (you’d better use the latest toolchain like Java 21 for the build, and use 
JavaCompile.options.release=11
to target Java 11. Then you get the latest bugfixes for 
javac
(==you avoid compiler bugs), and you still produce code that is perfectly executable with Java 11.
p
(I have to go offline, will get back to this thread for sure! thanks for your engagement)
👍 1
on the toolchain, yes - I'm aware of it, and I track it in Build using newest JDK, still producing JDK 11 bytecode
💯 1
let me just leave it here mainly for myself: https://blog.alllex.me/posts/2023-11-03-liberal-library-tooling/ ( I have it bookmarked for months 😄 just didn't manage to digest it properly)
So, I merged https://github.com/typesafegithub/github-workflows-kt/pull/2004 to preserve compatibility for all server clients, and this buys me some time to figure out how to keep this compatibility for further Kotlin metadata version updates
🎉 1
This way no part of the user base is lost
3 Views
Open in Slack
PreviousNext
Powered by