https://kotlinlang.org logo
e

Erik

09/10/2020, 7:28 AM
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
1
s

stephanmg

09/10/2020, 7:37 AM
So the tag is correct, but the header is wrong in the description?
e

Erik

09/10/2020, 7:38 AM
Exactly
s

stephanmg

09/10/2020, 7:38 AM
Ah I see, can’t you open an issue in that project?
no red 1
e

Erik

09/10/2020, 7:38 AM
Issues aren't available to me in that repo
I could open a youtrack issue
s

stephanmg

09/10/2020, 7:39 AM
Ah I see, I also cannot open an issue. Interesting.
e

Erik

09/10/2020, 7:39 AM
But this is a matter of someone with the correct rights changing a release name
s

stephanmg

09/10/2020, 7:39 AM
Yeah
I see no contact details for the author
e

Erik

09/10/2020, 7:39 AM
Hence my post here, this could have been fixed within a second
s

stephanmg

09/10/2020, 7:40 AM
I agree.
e

Erik

09/10/2020, 7:40 AM
It's not a big deal, so I won't ping more people
✔️ 1
s

stephanmg

09/10/2020, 7:41 AM
Sounds like YouTrack issue would be overkill 🙂
e

Erik

09/10/2020, 7:41 AM
I could mention a lot of main Kotlin contributors here, for spam 😉
s

stephanmg

09/10/2020, 7:41 AM
Yeah, it’s a very non-issue basically I agree
Maybe somebody notices it and brings it to the attention of te author
e

Erik

09/10/2020, 7:42 AM
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.
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
✔️ 1
o

Orhan Tozan

09/10/2020, 9:57 AM
Anyone knows why it jumped from 1.4.0 to 1.4.10 instead of 1.4.1?
j

Jurriaan Mous

09/10/2020, 10:12 AM
See release of 1.1.50:
Copy code
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/
s

stephanmg

09/10/2020, 10:26 AM
oh, that’s a little ugly
s

Szlagowskipatryk

09/10/2020, 10:40 AM
according to the seemver, it's a valid way
c

christophsturm

09/10/2020, 10:58 AM
“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?
s

stephanmg

09/10/2020, 11:23 AM
@Szlagowskipatryk semver?
e

Erik

09/10/2020, 11:24 AM
semantic version numbering
s

stephanmg

09/10/2020, 11:24 AM
yeah I am aware of semantic versioning
was confused because @Szlagowskipatryk wrote “seemver” 🙂
e

Erik

09/10/2020, 11:26 AM
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)
So I guess that it's true that 'incrementing' from 1.4.0 to 1.4.10 adheres to semver
s

stephanmg

09/10/2020, 11:26 AM
maybe it’in semver/semver on Github?
e

Erik

09/10/2020, 11:32 AM
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?
s

stanislav.erokhin

09/10/2020, 12:40 PM
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!
👍 1
o

Orhan Tozan

09/10/2020, 12:43 PM
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)
👍 1
s

stanislav.erokhin

09/10/2020, 12:46 PM
because not everyone use semver and sometimes comparison happens just lexicographically 😞
e

Erik

09/10/2020, 12:47 PM
Too bad that's what you have to deal with as a language developer for multiple platforms
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!
3 Views