<https://github.com/JetBrains/kotlin/releases/tag/...

# feed

[Ayfri]

https://github.com/JetBrains/kotlin/releases/tag/v1.6.10

[Klitos Kyriacou]

Nice to see it's finally been released. I haven't tested it with IDEA 2021.3 yet, but I hope everything will work fine. By the way, I've just noticed all the files in the zip for the standalone compiler are dated 1-Feb-1980 (and have always been). Is that date of any particular significance, such as a birthday, I wonder?

[Jilles van Gurp]

Just a comment from my side that the last few releases have been a bit messy in terms of alignment in the wider ecosystem. For example coroutines has not been updated yet for 1.6. There's an RC out there right now but it's not released yet. It seems that for every minor release, it takes a good chunk of the release cycle to get everything updated; even just the various Jetbrains libraries.

Both for 1.5 and 1.6 I had the issue that it took several weeks before I could actually migrate our projects to use it because of various libraries not yet having been updated to support the latest release. In both cases I rolled back a pretty big PR to update because I realized that several key things that I needed had not released yet.

The last few releases seem to have been very disruptive for a minor release that happens every three months or so. We use a lot of the cutting edge stuff so I'm used to solving problems but still, the dot zero releases have basically been unusable for us lately. Maybe it's time to figure out a less disruptive way to do releases? For example Eclipse has had a their release cycles where they basically released everything they had in one go instead of releasing things one by one. That seems to have worked well for them.

[ilya.gorbunov]

Is that date of any particular significance, such as a birthday, I wonder?

No, it's just the date Gradle uses for files inside .zip/.jar when we ask it to erase timestamps. We do it to achieve reproducible builds, so that the same sources produce the same archive bytes.

[ilya.gorbunov]

@Jilles van Gurp Usually you do not have to wait for the libraries to be released before updating the Kotlin version. The existing library versions should (mostly) work fine with new versions of Kotlin. Do you have any specific issues?

[ribesg]

Until recently you 100% had to wait for every single lib to update when doing Kotlin/Native stuff. TBH it’s still the case with the new memory model now. Also, the latest version of the Kotlin IDE didn’t even support the latest version of Kotlin. That’s the kind of issues that shouldn’t happen.

Right now my project still don’t work with the latest version of everything, I lost today investigating that. Leaning toward the latest version of the IDE or the Kotlin plugin not working with Android gradle build tools 7.0.4 or something like that.

It would be nice if we could reach a point where stable means something again for x.0 versions

[Jilles van Gurp]

We are running into issues with transitive dependencies requiring updates before we can even move. Things like spring, expedia graphql, and in our frontend things like fritz2 and a few other libraries. I think with our multi platform projects we also ran into some bugs that basically resulted in the advice to stick with 1.5.32 until 1.6.10 was out. The last few releases the compiler changes has generated a lot of extra work as well.

Jetbrains could simplify this by simply orchestrating their releases to happen at the same time. The versioning for a lot of these things in any case suggests that you are supposed to match the minor version with the kotlin version. I'm just making the point here that the work this is generating seems to be increasing for everyone and this is causing everyone to slow down the pace at which they are updating. Which of course adds to the problem.

[ribesg]

I just stopped updating to the next major version. Waiting for the x.10 (or, really, x.20) is the new default now

[elizarov]

I’m really sorry for that. We are working hard to boost our test coverage and QA, so that we can find all the problems ourselves before release, and make our x.0 releases stable. With respect to libraries, we don’t plan to align releases. It’s not just our libs, it’s the whole community. So we are doubling down on our backwards compatibility promise. It means that if anything new is not compatible with old libs, then it’s a bug (please file one if you noticed it). We’ll fix it and we will make sure it is covered by tests, so that it does not repeat again in the next release.