Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kotlin version mismatch possible when using bindings from server #1756

Open
krzema12 opened this issue Dec 31, 2024 · 3 comments
Open

Kotlin version mismatch possible when using bindings from server #1756

krzema12 opened this issue Dec 31, 2024 · 3 comments
Labels
problem Not really a bug, but something isn't right.

Comments

@krzema12
Copy link
Member

krzema12 commented Dec 31, 2024

Context

Kotlin compiler's version used by the bindings server is regularly updated, and generally tracks the newest one. Also, the bindings server is the default, recommended way of consuming action bindings.

Problem

If someone uses a Kotlin version that is not compatible with the one that the bindings server used to compile the bindings, the compiler complains:

error: module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 2.1.0, expected version is 1.8.0. (main.kotlin_module)
error: incompatible classes were found in dependencies. Remove them from the classpath or use '-Xskip-metadata-version-check' to suppress errors
.github/workflows/branches-and-prs.main.kts:24:59: error: class 'io.github.typesafegithub.workflows.actions.actions.Checkout' was compiled with an incompatible version of Kotlin. The actual metadata version is 2.1.0, but the compiler version 1.8.0 can read versions up to 1.9.0.
The class is loaded from /Users/piotr/.m2/repository/actions/checkout/v4/checkout-v4.jar!/io/github/typesafegithub/workflows/actions/actions/Checkout.class
import io.github.typesafegithub.workflows.actions.actions.Checkout
                                                          ^

Ideas

  • use the newest Kotlin version on the server, but tell it to produce output with fixed metadata (possibly to support a few years in the past?)
    • not sure if Kotlin gives us such an option
  • expose multiple artifacts/versions/server routes, to give the user the control of the version of Kotlin the bindings are compiled with
    • this can easily get unbearably complex, TBD
@krzema12 krzema12 added the problem Not really a bug, but something isn't right. label Dec 31, 2024
@LeoColman
Copy link
Contributor

In Java we usually do

  • Compile with Java 8
  • Run on Java 250 no problem

Can't we use Kotlin 1.5 to compile things on the server and that would provide enough compatibility?
Naturally we don't need to go that low, but backwards compatibility should be possible


Maybe Kotlin has something like "CompileVersion"/"SourceVersion" same thing as Java?

@krzema12
Copy link
Member Author

Yes, that's the idea I'd like to try out first, perhaps I'll reorder the ideas in the issue description.

@krzema12
Copy link
Member Author

krzema12 added a commit that referenced this issue Jan 1, 2025
Part of #1756.

The goal here is to both depict the current behavior, but also save us
from unintentionally having Renovate auto-merge PRs that bump Kotlin
version, which results in having incompatibility in Kotlin Metadata. The
details of the problem are described in #1756.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
problem Not really a bug, but something isn't right.
Projects
None yet
Development

No branches or pull requests

2 participants