-
Notifications
You must be signed in to change notification settings - Fork 834
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
Target kotlin 1.6 in kotlin extension #5910
Conversation
extensions/kotlin/build.gradle.kts
Outdated
@@ -48,6 +48,8 @@ tasks { | |||
withType(KotlinCompile::class) { | |||
kotlinOptions { | |||
jvmTarget = "1.8" | |||
// earliest version supported by kotlin 1.9 | |||
languageVersion = "1.4" |
There was a problem hiding this comment.
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 ReportAll modified and coverable lines are covered by tests ✅
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. |
There was a problem hiding this 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.
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
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. |
I have very little kotlin experience, so I'll leave this to the experts. |
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) |
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. |
@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:
|
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. |
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. |
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 One thing to keep an eye on is that this repo seems to set the |
@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? |
Yeah definitely, I also think we shouldn't force Maybe just a simpler option is to always keep the
No, I just tried it locally and, if I set my kotlin version to
I also tried with |
As far as I understand kotlin compiler accepts metadata that is at most one version ahead of its version.
#5903 (comment) states that
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. |
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. |
17a9fae
to
5cecfe7
Compare
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