Kotlin evolution principles

In this topic, we will tell you about how the Kotlin language develops. You will learn the principles of its evolution and how you can be involved in that process. You’ll also find out how to understand the essence of the changes according to the update version and what levels of stability the language has.

Kotlin evolution

Kotlin is an open-source programming language first introduced in 2010. Since then, the language has been developing and acquiring new features that meet modern development trends. It is maintained by JetBrains and many open-source contributors.

For ten years, Kotlin’s lead designer was Andrey Breslav, but in November 2020, he stepped down and Roman Elizarov took the role of the lead designer.

Anyone who wants to contribute to the language development process has the following options:

• Kotlin Evolution and Enhancement Process (KEEP). This is the process to make proposals on adding new features in the scope of KEEP. This process is described in detail in the corresponding GitHub repository.
• Contribution. As an open-source contributor, you have several options to choose from. You can participate in the Early Access Preview (EAP) and contribute to the development of various libraries, the compiler, and Kotlin IDE plugin. Another way of contributing to the language may be the development of educational materials: improving the documentation or making tutorials and videos. Here is the link to the Contribution page if you think this option is exactly what you want to do.
• Fixing bugs. Found a bug and want it to be fixed? The Kotlin issue tracker is public. Additionally, you are free to suggest incompatible changes (removing or changing existing features) to the language. Follow the procedures described in the Kotlin Foundation website to submit your proposal.

Principles of pragmatic evolution

Kotlin tends to be a pragmatic programming language following these three principles:

• Keep the language modern over the years. Programs accumulate legacies over time. Technologies are getting old, so the language must evolve to meet current needs. For this purpose, it is important not only to add new features but also to phase out some old ones.
• Stay in the constant feedback loop with the users. Adding new features to the language is a serious step. You need to test the new functionality in action to avoid deprecations in the future. In this respect, users who test updates and give feedback can make a significant contribution. Pre-release versions serve this purpose. Trying them out, users make a huge contribution to the improvement of the language.
• Make updating to new versions comfortable for the users. Incompatible changes in the language, such as removing features from it or reshaping them, can become a headache for users. Therefore, they should be prepared for the upcoming changes with the help of compile-time warnings, the deprecation mechanism, and automated migration tools.

At JetBrains, changes in Kotlin are regulated by the community and the Kotlin Foundation. The language evolution is overseen by the lead designer, who has the final say in this matter, but incompatible changes should be approved by the Language Committee of the Kotlin Foundation.

Kotlin releases

Updates in Kotlin are divided into two types:

• Feature (major) releases (1.x.0 or 1.x). Also known as stable releases, these are major changes to the language, generally adding new features and removing or changing deprecated features. Such updates happen about once every six months, sometimes a little longer. Before publishing such versions, one or more EAP (Early Access Preview) builds may be released to gather feedback from the community.
• Incremental (minor) releases (1.x.y). Those are updates between feature releases, and they bring Standard library API improvements, performance improvements, bug fixes, tool updates, the preview of new language features, etc.

For instance, 1.4.0 (also known as 1.4) is a feature release version, and 1.4.20 is an incremental release version. Of course, feature releases can also bring incremental updates. If you are curious about a detailed overview of different Kotlin version updates, you can explore The Kotlin Blog content.

Stability of components

Earlier we mentioned the principles of Kotlin language development based on feedback received from users. For this purpose, before the release of a stable version, several pre-stable versions are released to let users test updates and express their opinion. These version stages are defined by the level of their readiness and the risk users take when working with them. The levels of stability are:

• Experimental. Such a stability level means there is an idea that should be tried out. The target is to let some users play with it and give feedback. If it doesn’t work out, we may drop it any minute. These releases are recommended to try only in toy projects.
• Alpha. This level means there has been a decision to productize this idea, but it hasn’t reached the final shape yet. You should use these releases at your own risk, expecting migration issues.
• Beta. It’s a sign that things are almost done but changes are possible. Watch out for deprecation warnings. If you wish, you can use these versions – everything possible will be done to minimize migration issues.
• Stable. This level shows that the feature is ready to be used and it will evolve following the backward-compatibility rules.

Stability levels can be seen in GitHub repositories as badges. For example, by July 2022 kotlinx-datetime is in the alpha stage.

Conclusion

Here, we have revealed to you the cornerstones of the Kotlin programming language development. You have learned according to what principles the language changes and what the numbers of the language versions mean. In addition, now you know how to distinguish between language updates by the level of stability so that you can make the right decision when using new features.