https://kotlinlang.org logo
Join Slack
Powered by
Why is `kotlin-wrappers` already depending on 1.8....
# javascript
v
Why is 
kotlin-wrappers
already depending on 1.8.20? It is not yet officially released. 😕
a
You can already install 1.8.20, the EAP docs are already listing a lot of the changes from this update
v
You can use it, yes, it is available on Maven Central. But you shouldn't. As with every release, it needs a few days until everything is in place and until the Blog post appears, it is not officially released and should not be used.
t
You can use it, yes, it is available on Maven Central.
But you shouldn’t.
Why it doesn’t work the same way for 
kotlin-wrappers
? 🙂
v
Because you do not have such a rule, that releases are only to be used when officially announced.
Besides that this procedure is disturbing and unnerving, especially with people using automatic dependency update bots and then wonder why things do not work properly if they use half-released versions.
t
How bots understand, that new version of Kotlin can be used? Is there special flag “officially announced”?
v
Unfortunately not, that's exactly the problem. As far as I know people using such bots and being aware of this aweful situation configure it either to ignore Kotlin or to delay suggesting a Kotlin update for 1 or 2 weeks in which time it usually is officially ready.
t
From our side it’s also important to know, that we are compatible with new Kotlin version 🤨
v
Of course, but depending on a not fully released version is like depending on an rc or snapshot or similar. It is bad to do so, especially in a library. I intended to switch to latest version and suddenly got my Kotlin version upgraded to a not-fully release version.
Besides that you usually should depend on the lowest version of dependencies you support, not on the latest. Like it is now, 
kotlin-wrappers
latest version says "I need 1.8.20 and nothing less".
t
Are you from “Java world”? 🙂
v
Yes, but that shouldn't make any difference
Especially as that is Gradle logic and Maven logic and Ivy logic and Npm logic, ..., not Java logic
t
Like it is now, 
kotlin-wrappers
latest version says “I need 1.8.20 and nothing less”.
It’s what we really check on our projects
I mean - usually we check wrappers on latest version only
v
Yeah, well, if that is what you want to say, it's fine, except for the fact that it is a not-fully released version. I tend to be more open to older versions in my library projects to be a bit more compatible. Not everyone can always immediately use latest versions of things, especially in bigger projects. 🙂
t
Not everyone can always immediately use latest versions of things, especially in bigger projects. 🙂
I suppose they don’t update wrappers every day 🙂
I tend to be more open to older versions in my library projects to be a bit more compatible.
Special notes in CHANGELOG?
v
Don't know what you mean. Besides that it is not "Kotlin 1.8.20 support", but "Requires now Kotlin 1.8.20", I have no idea why you answer with that link to the quoted statement. Yes, you notify your users about the 1.8.20 move. That was not the point.
Well, let's just stop it here. You want to only support the latest Kotlin version always and that is fine, it is your project. And you want to require a not yet fully released version, that's not so fine, but welll, it is your project and I just don't upgrade further until it is officially released, like with other libs that have the funny idea to depend on unfinished work. 🙂
t
@Vampire Your comments are important. But I can’t use it directly. It doesn’t work the same way as for Java libraries unfortunately. I have related problems with versions. Android needs Kotlin 
1.8.10
, Kotlin/JS needs Kotlin 
1.8.20
- what would be fine solution?
v
Well, don't use a not-fully released version. 😄
But other than that, just normal conflict resolution. If 1.8.10 is supported, 1.8.20 should too, so default conflict resolution in Gradle would pick 1.8.20
t
Compose won’t support Kotlin 
1.8.20
next/this week :(
Official announcement will change nothing
v
They only support an exact specific version? o_O
Well, that's even worse than 
kotlin-wrappers
then. 😄
t
We have releases for all stable Kotlin versions 🙂
And even for “not-fully” released
For my project Kotlin 
1.8.20
works fine right now With required fixes for IR compiler
They only support an exact specific version? o_O
1.8.0
supported officially
v
Compose won’t support Kotlin 
1.8.20
next/this week :(
Did you mean "will not support" as in "will not officially announce that they support it" or as in "it fails if you try to use 1.8.20"?
Because any sane project I know means with "supports version x.y.z" x.y.z and any newer version, or at least within the same major or minor version. 😄
t
“it fails if you try to use 1.8.20”?
Yes
v
😢
But well, there you have why it is bad if some libraries force you to always the latest version. 😄
t
Compose forces you to use previous version 🙂
v
Present version, you said it works with 1.8.10 😛
t
Only with suppress
v
But yeah, didn't say that is nice either. But the more libraries force single specific versions, the worse it is to combine them in a project
Good old joy of dependency hell 😄
l
They said when Compose was first released that the Kotlin plugin SDK isn't quite stable yet in terms of breaking changes. I believe the goal was to change this in Kotlin 2.0, but not 100% sure if that's on track. Because of this, Compose needs to be modified for each Kotlin version.
e
Compose has multiple parts. The Compose compiler plugin is fairly strictly tied to exact compiler releases. The rest of the runtime is not (neither to the Kotlin version nor the compiler plugin version).
8 Views
Open in Slack
PreviousNext
Powered by