Kotlin 1.1.50 EAP

EAP
1

We’re happy to announce the EAP for Kotlin 1.1.50.

What’s new

  • New versioning scheme: 1.1.5x instead of 1.1.5-x
  • Improved support for JSR-305 annotations (nullability problems can be reported as warnings, checks work when JSR-305 classes are not on the classpath)
  • Performance improvements for generated bytecode
  • Lots of bugs are fixed in the compiler and IDE
  • New inspections, performance improvements and bugfixes in the IntelliJ plugin
  • Also in JS backend:
    – Improved inliner and primitive arrays to TypedArray translation enabled by default (breaks binary forward compatibility)
    – Source maps support in DCE
    – Fixes for Unit materialization

Full changelog

How to get EAP build

For IntelliJ IDEA:

You can configure Early Access Preview channel in Tools → Kotlin → Configure Kotlin Plugin Updates. Change the update channel to “Early Access Preview 1.1.x” and press Check for updates now.

For Gradle or Maven:

Add https://dl.bintray.com/kotlin/kotlin-eap-1.1 to your repositories.
Change the version of Kotlin dependencies (compiler and stdlib) to 1.1.50-eap-18

Please do provide feedback and report any issues to our issue tracker (please specify your plugin version and IDE version).

3 Likes
2

The new versioning scheme seems…confusing. Can you elaborate on why that choice was made?

2 Likes
3

As far as I know the versioning change is mainly due to the fact that NPM treats versions with the dash as pre-release. It considers 1.1.5 to be more recent than 1.1.5-3 (which is incorrect for Kotlin). As a result expressing “give be version 1.1.5 or later” becomes quite complicated. Changing the versioning scheme solves this problem.

4

Hm, short of dropping your “hotfix” suffix and just incrementing the patch version (e.g. turning 1.1.5-1 into 1.1.6), this seems like the next best option. Too bad the Z can’t end in a letter, e.g. 1.1.5, 1.1.5b, 1.1.5c.

1 Like
5

Why not 1.1.5.3?

1.1.50 looks really… confusing

1 Like
6

True, looked for version 1.1.49. lol

7

NPM follows semver, which doesn’t allow the fourth number. So 1.1.5, 1.1.5-3, and 1.1.50 are valid versions, whereas 1.1.5.3 isn’t.

8

Does Kotlin follow semver?

In such case I consider 1.1.6 really clearer (as proposed by @nanodeath).

2 Likes
9

Kotlin 1.1.50-eap-28 is out: JFrog Distribution: Get your software to where it needs to be -- ASAP!

10

We can’t do that, because hotfix releases are often published after the EAP for the next release starts. We can’t publish 1.1.6 EAP and then publish 1.1.6 release which doesn’t contain any of the changes which were included in 1.1.6 EAP.

3 Likes
11

Also we cannot just drop the first ‘1’ due to the compatibility guarantees

12

All reasons look good :confused:

The last undiscussed reason is to follow the semver only on platform wich it is required.

13

I still believe it would’ve just been simpler, if the team wants to use SemVer, to actually stick to SemVer. These “patch” releases largely should be minor versions (i.e., 1.x.y instead of 1.1.x-y or 1.1.xy). For features targeted for bigger milestones like 1.1 or 1.2, put them behind feature gates and just enable them when they’re stable.

14

We don’t want to use semver; we have to use semver-compatible version numbers because of npm.

15

This is currently true only for npm releases.

16

What you say implies releasing the same version under different version numbers on different platforms, if I understand you correctly. This should really not be done - that will only lead to confusion.

After this we will all get used to the new numbering scheme and there will be no issue.

17

So there will never be a 2 digits version?
I’m already imagining a version 1.1.111 and be like… is this 1.1.11-1 or 1.1.1-11?

18

That should be unlikely. The last “hotfix” number is typically no more than 3.

19

I think separate version numbering for npm and the rest would bring about more confusion than this. It’s probably better to keep things consistent.

1 Like