What's everyone planning to do with 1.7 around the...
# library-development
m
What's everyone planning to do with 1.7 around the corner? 1️⃣ Upgrade my lib asap, moving the ecosystem faster 🚀 2️⃣ Wait a bit for consumers to update first so that they have less compatibility issues 🧘
2️⃣ 2
1️⃣ 9
j
Except if the Renovate PR fails, it will be merged instantaneously
m
It might be a pain for consumers though. It'll force every app on 1.7
j
1.7 should be compatible with 1.6
m
Define "compatible"
Pretty sure some users using KGP 1.5 will start failing with "cannot read metadata version 1.7"
j
I think 1.7 was going to be compatible with 3 previous version (1.4 included)
m
Right so setting
languageVersion = 1.5
(in the lib)
That's not enough, it still fails with
Copy code
Class 'kotlin.Unit' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.7.1, expected version is 1.5.1.
j
I haven't tried yet, but I don't like to stick not updating the library, if someone can't update Kotlin to 1.7.0, the previous version of the library will be there until it is possible
if the ecosystem stops updating constantly... Java 8 vibes
3
m
I agree 100% but feels better if the ecosystem moves in a coordinated way? Having libs lag a bit doesn't sound too terrible to me, this is why there are tools like
apiVersion
and
languageVersion
in the first place
I know for a fact that for some codebases, bumping the Kotlin version requires non-trivial effort so giving a couple of months of headstart seems like a reasonnable thing?
g
I'm really afraid of Compose/Kotlin relationship : my app uses Compose and an open-source lib of mine -> If I upgrade the lib to 1.7.0, I'll not be able to use it on my app for weeks...
I presume forcing a new version of Kotlin for Compose will make (subtle) errors, this may be wrong 🤔
m
You can still use a lib compiled.with 1.7 with the 1.6 compiler (as long as you're not using any new features). That part works afaik
The pb is for kotlin 1.5 users
e
IMO: if you want to support consumers that want to be loaded into gradle classpaths, then you should definitely stick to older Kotlin. but I believe that isn't be true of most libraries, and other (JVM) environments can safely use kotlin-stdlib 1.7 even if compiled with Kotlin 1.6. if there's consumers stuck on Kotlin 1.5 or earlier… well that sucks, you'll have to decide what level of support you want to offer them. but I don't expect many of those outside of Gradle
m
Makes sense. The thing is being a lib, it's hard to tell where it's going to end up being used
I think ultimately, something like upgrading to KGP to 1.7 so that I can benefit from the incremental compilation changes, etc but keeping
languageVersion=1.6
for a while is a nice compromise
1