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

# announcements

[Erik]

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

[stephanmg]

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

[Erik]

Exactly

[Erik]

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

[stephanmg]

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

[Erik]

This should be v1.4.10: https://github.com/jetbrains/kotlin/releases/tag/v1.4.10

[Erik]

Issues aren't available to me in that repo

[Erik]

I could open a youtrack issue

[stephanmg]

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

[Erik]

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

[stephanmg]

Yeah

[stephanmg]

I see no contact details for the author

[Erik]

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

[stephanmg]

I agree.

[Erik]

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

[stephanmg]

Sounds like YouTrack issue would be overkill 🙂

[Erik]

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

[stephanmg]

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

[stephanmg]

Maybe somebody notices it and brings it to the attention of te author

[Erik]

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.

[Erik]

Some repos I follow only create releases with descriptive names, but excluding the tag name, which means I have to go look at the release to find out the specific tag

[Orhan Tozan]

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

[Jurriaan Mous]

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/

[stephanmg]

oh, that’s a little ugly

[Szlagowskipatryk]

according to the seemver, it's a valid way

[christophsturm]

“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?

[stephanmg]

@Szlagowskipatryk semver?

[Erik]

semver.org

[Erik]

semantic version numbering

[stephanmg]

yeah I am aware of semantic versioning

[stephanmg]

was confused because @Szlagowskipatryk wrote “seemver” 🙂

[Erik]

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)

[Erik]

So I guess that it's true that 'incrementing' from 1.4.0 to 1.4.10 adheres to semver

[stephanmg]

maybe it’in semver/semver on Github?

[Erik]

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?

[stanislav.erokhin]

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!

[Orhan Tozan]

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)

[stanislav.erokhin]

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

[Erik]

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

[Erik]

I think that the current versioning scheme is very close to what you usually see with semver, and if it works for all the release use cases: fine with me!