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

Target kotlin 1.6 in kotlin extension #5910

Merged
merged 5 commits into from
Nov 17, 2023

Conversation

laurit
Copy link
Contributor

@laurit laurit commented Oct 12, 2023

Resolves #5903
1.4 should be the earliest supported version for 1.9 compiler, probably we'll have to bump this with the next kotlin version

@laurit laurit requested a review from a team October 12, 2023 11:57
@@ -48,6 +48,8 @@ tasks {
withType(KotlinCompile::class) {
kotlinOptions {
jvmTarget = "1.8"
// earliest version supported by kotlin 1.9
languageVersion = "1.4"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this also applies to the tests. Could also use

compileKotlin {
  kotlinOptions {
    languageVersion = "1.4"
  }
}

@codecov
Copy link

codecov bot commented Oct 12, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (531898c) 91.18% compared to head (256f4c7) 91.18%.

Additional details and impacted files
@@            Coverage Diff            @@
##               main    #5910   +/-   ##
=========================================
  Coverage     91.18%   91.18%           
  Complexity     5613     5613           
=========================================
  Files           616      616           
  Lines         16566    16566           
  Branches       1642     1642           
=========================================
  Hits          15105    15105           
  Misses         1013     1013           
  Partials        448      448           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@jack-berg jack-berg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, but wondering if folks with more kotlin experience like @breedx-splk / @jkwatson / @LikeTheSalad can chime in to confirm.

@LikeTheSalad
Copy link
Contributor

This looks good to me, but wondering if folks with more kotlin experience like @breedx-splk / @jkwatson / @LikeTheSalad can chime in to confirm.

I was actually having issues with this lib forcing me to upgrade Kotlin a couple of days ago though I could sort it out by upgrading to Kotlin 1.8, I tried 1.9 first but that caused a bunch of other issues with other dependencies and it was a mess.. Luckily 1.8 worked out well, still I'm glad this change is being added because I understand that upgrading Kotlin can be painful sometimes. Tbh I've never used the config languageVersion before, but it seems the right approach without having to downgrade the Kotlin version used in this project.

1.4 should be the earliest supported version for 1.9 compiler, probably we'll have to bump this with the next kotlin version

I think 1.4 is a great option. In the Android gradle plugin they made 1.5 a requirement a while ago, so I wouldn't mind bumping it up in the next kotlin version in case 1.4 is no longer supported by then.

@jkwatson
Copy link
Contributor

This looks good to me, but wondering if folks with more kotlin experience like @breedx-splk / @jkwatson / @LikeTheSalad can chime in to confirm.

I have very little kotlin experience, so I'll leave this to the experts.

@trask
Copy link
Member

trask commented Oct 13, 2023

I think 1.4 is a great option. In the Android gradle plugin they made 1.5 a requirement a while ago, so I wouldn't mind bumping it up in the next kotlin version in case 1.4 is no longer supported by then.

since this artifact is marked stable, would dropping support for older kotlin version be considered a breaking change? (in the instrumentation repo this is why we encode the base version into the artifact name)

@LikeTheSalad
Copy link
Contributor

since this artifact is marked stable, would dropping support for older kotlin version be considered a breaking change?

I think so, because in my case my project stopped compiling until I bumped its Kotlin version. However, it seems like Kotlin is dropping support for older language versions with every new minor version bump release, so it seems unavoidable to drop support for 1.4 at some point, unless we pin this project's Kotlin version to the last one that supports 1.4.

@jack-berg
Copy link
Member

@trask are you suggesting that this PR is a breaking change or that upgrading to 1.5 after merging this PR would be a breaking change?

@trask
Copy link
Member

trask commented Oct 18, 2023

@trask are you suggesting that this PR is a breaking change or that upgrading to 1.5 after merging this PR would be a breaking change?

the latter, and this was what got my attention:

probably we'll have to bump this with the next kotlin version

@jack-berg
Copy link
Member

Hmm.. so the question is should we do something now do accommodate upgrading the minimum kotlin version (or at least have a plan for how we would handle it), or should we codify that we don't consider upgrading the kotlin version a breaking change.

Was looking at the okhttp changelog the other day and noticed that they upgrade the kotlin version in minor release versions.

@jack-berg
Copy link
Member

This is related to the minimum android conversation in #5936. I think we should codify that upgrading the minimum android version should not require a new major version, and that the same advice applies to kotlin. Would be good to define some logic for how we choose the minimum kotlin version and document it.

@LikeTheSalad
Copy link
Contributor

LikeTheSalad commented Nov 6, 2023

Would be good to define some logic for how we choose the minimum kotlin version and document it.

For Android purposes, I believe a good measure could be the AndroidX libs. They are the official Android tools outside of the Android SDK.

They are also the reason why many times I've had to upgrade my kotlin version after upgrading one of them due to compilation issues caused by kotlin version conflicts.

It seems like they've recently upgraded to kotlin 1.9, and set the languageVersion from 1.5 to 1.8. I'm not sure why they've jumped straight to 1.8 though, probably there were not many breaking changes from 1.5 up to 1.8... Though I'm not fully sure. In any case, I think this repo should be a good guide on what kotlin version to use when it comes to Android projects, not sure about non-android projects that use kotlin though.

One thing to keep an eye on is that this repo seems to set the languageVersion in two places, one for their build tools here and one for their deliverable projects here (which is later set to subprojects here). They're both set to 1.8 atm so it's not a problem, but it's probably worth taking a look at both once in a while.

@jack-berg
Copy link
Member

@LikeTheSalad I think upgrading to 1.9 would conflict with the original issue #5903 in which @laurit describes that Spring boot 2.7.x users require 1.6.21.

Although, after writing that, I'm not sure why a spring boot 2.7.x user couldn't upgrade kotlin to a later version than 1.6.21. Is kotlin 1.9 not compatible with 1.6.21?

@LikeTheSalad
Copy link
Contributor

@LikeTheSalad I think upgrading to 1.9 would conflict with the original issue #5903 in which @laurit describes that Spring boot 2.7.x users require 1.6.21.

Yeah definitely, I also think we shouldn't force 1.9 compatibility (which is the case right now), and the AndroidX lib I mentioned earlier doesn't force it either because they set their languageVersion compilation param to 1.8 which ensures compatibility with versions older than 1.9. So my comment above was more about what's the lowest languageVersion we could set to keep compatibility with older kotlin versions, and at least for Android, it seems like it could be 1.8 right now based on AndroidX libs, although that still seems pretty high.

Maybe just a simpler option is to always keep the languageVersion to the minimum non-deprecated one, which seems to be 1.6 right now. It's probably what @laurit was trying to do anyway, to use the minimum compat version supported.

Is kotlin 1.9 not compatible with 1.6.21?

No, I just tried it locally and, if I set my kotlin version to 1.6.21 while I have a dependency built with kotlin 1.9.x, I get this compilation error message:

Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.6.0.

I also tried with 1.7.x with the same results. Only 1.8.x seems to be compatible with 1.9.x for some reason.

@laurit
Copy link
Contributor Author

laurit commented Nov 9, 2023

Only 1.8.x seems to be compatible with 1.9.x for some reason.

As far as I understand kotlin compiler accepts metadata that is at most one version ahead of its version.

Although, after writing that, I'm not sure why a spring boot 2.7.x user couldn't upgrade kotlin to a later version than 1.6.21. Is kotlin 1.9 not compatible with 1.6.21?

#5903 (comment) states that

Another alternative could be to use a newer Kotlin version than 1.6.21 myself but I don't know which consequences that would have.

Our choices are to choose the minimum kotlin version which we wish to support and avoid updating kotlin dependency for this module or keep updating the kotlin dependency and set the target to earliest supported version. Either is better than what we do now.

@jack-berg
Copy link
Member

or keep updating the kotlin dependency and set the target to earliest supported version

Let's do this, and document this strategy in versioning. Avoiding updating the kotlin dependency is too restrictive without any strong justification. I'd like to retain the flexibility to update the kotlin version in the future.

@laurit laurit force-pushed the kotlin-extension-kotlin-version branch from 17a9fae to 5cecfe7 Compare November 17, 2023 06:48
@jack-berg jack-berg merged commit c87852c into open-telemetry:main Nov 17, 2023
18 checks passed
@jack-berg jack-berg changed the title Target kotlin 1.4 in kotlin extension Target kotlin 1.6 in kotlin extension Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should opentelemetry-extension-kotlin have a lower languageVersion?
5 participants