https://github.com/jetbrains/kotlin/releases/tag/v1.4.10 has just been released, but the release name on GitHub is incorrect: it says 'v1.4.0' I already notified @stanislav.erokhin about this (he made the release), but I'm not sure if he reads messages on this Slack environment. @JB

So the tag is correct, but the header is wrong in the description?

Exactly

Ah I see, can’t you open an issue in that project?

This is v1.4.0: https://github.com/JetBrains/kotlin/releases/tag/v1.4.0

Ah I see, I also cannot open an issue. Interesting.

But this is a matter of someone with the correct rights changing a release name

Yeah

Hence my post here, this could have been fixed within a second

I agree.

It's not a big deal, so I won't ping more people

Sounds like YouTrack issue would be overkill 🙂

I could mention a lot of main Kotlin contributors here, for spam 😉

Yeah, it’s a very non-issue basically I agree

The biggest downside is that people, like me, who are subscribed to Kotlin release notifications on GitHub, receive an incorrect notification: 'Kotlin v1.4.0'. I was confused about this. It's a GitHub issue that they only notify by release name, and don't mention any tag.

Anyone knows why it jumped from 1.4.0 to 1.4.10 instead of 1.4.1?

See release of 1.1.50:

Versioning scheme change
Starting with this release instead of using versions 1.1.5, 1.1.5-1, 1.1.5-2, etc. versions 1.1.50, 1.1.51, 1.1.52 will be used.

We want to publish our JS artifacts to NPM with the same version number as the version of the release. The issue here is that we use the number after that dash as the hotfix number, while NPM considering versions with the dash as being pre-release. This means that NPM considers Kotlin 1.1.5 to be more recent than 1.1.5-1, whereas the opposite is actually true. Changing the versioning scheme fixes the problem.

https://blog.jetbrains.com/kotlin/2017/09/kotlin-1-1-50-is-out/

oh, that’s a little ugly

according to the seemver, it's a valid way

“The release contents the JVM version of the Kotlin compiler, and also the Kotlin/Native compiler for the supported platforms: Linux, macOS and Windows.” does that mean that libraries stay at 1.4.0?

@Szlagowskipatryk semver?

yeah I am aware of semantic versioning

Interestingly, semver.org doesn't mention by how much every number should increase when a new release is made. They mention that the numbers are 'incremented', but that doesn't necessarily mean by 1. (although, increment usually means by 1 in the context of software engineering)

maybe it’in semver/semver on Github?

What I don't get is that hotfixes aren't simply published as patch releases, e.g. instead of 1.1.5-1 just release 1.1.6. But maybe they want to release only for JS, not for other platforms, and stick to the same major.minor.patch scheme?

with 1.1.5 to 1.1.6 is difficult to distinguish big releases as 1.3.70 and patch updates like 1.3.71 Potentially we could use 1.4.1 for patch update of 1.4.0 but if by some reason the second patch update needed like 1.4.2, then for some system 1.4.2 would be newer then 1.4.10. btw @Erik Thanks for pointing out initial mistake. Fixed!

Why would some systems ever assume 1.4.2 > 1.4.10? Thats now how semver works. (Besides that, I am not sure if Kotlin is tryong to follow semantic versioning)

because not everyone use semver and sometimes comparison happens just lexicographically 😞

Too bad that's what you have to deal with as a language developer for multiple platforms