Ktor Roadmap – What’s Next
We’re one month into 2022, and on the Ktor team we’re focusing on finalizing the little that is left from our side on 2.0 and waiting for Kotlin 1.6.20 to be released so as to release 2.0. At the same time, we’re planning the next things to be worked on.
As some of you know, we had published our roadmap for 2020-2021 and while we didn’t manage to deliver on everything on it, we weren’t far off. However we also realized that we did in fact bite off more than we could chew.
This led us to try and figure out whether the whole approach to a roadmap where you have a fixed timeline actually works. It definitely is an industry standard, and even at JetBrains many folks practice it, but at the same time it does have its own issues. In particular, it’s based on the idea that not only can we estimate things quite well, but it also doesn’t account for external factors or disruptions that could cause us to change course.
Looking at the purpose of the roadmap, which is providing not only focus to the team on what we’re working on next, but also let all of you, our customers know what we’re working on, we decided to address these aspects as opposed to tie ourselves to a specific year.
As such, moving forward we will no longer be aligning our roadmap with natural years, but focusing on three different timeframes: short-term, mid-term, and long-term. The first of these is what our immediate focus is going to be on, and what we’ll be sharing publicly. As and when we complete things, we’ll move things from the mid-term to the short-term.
Given that, let’s focus on what we have lined up next!
Our short-term plans
The plan is distributed amongst different areas. In particular:
Infrastructure
From the infrastructure perspective, we still have a few areas that need addressing. We want to add YAML support for configuring applications, which is not only demanded by many of our users, but also already supported in the IDE. We also want to work on fixing some performance issues with Netty, as well as extract and implement a proper IO library with network support.
Long standing issues
We have 150 issues that are long-standing (many of them imported from GitHub). While it is impossible to resolve all of them, we do intend to address them and fix/schedule accordingly. One issue that definitely will be worked on is Swagger support.
Bootstrapping applications
We’ve made good efforts in making it easy to create new applications, but there are still many areas that need to be addressed. We are working on some cool things that will make starting with Ktor even easier for newcomers to the framework and to the JVM. We’ll be working on minimizing the amount of boilerplate code and set-up that needs to be done when it comes to working with databases.
Deployment
We currently provide steps and guides on how to deploy Ktor applications, but we want to make it smoother by automating deployment configurations.
Tooling Support
Over the past year we’ve managed to add quite a bit of support for IntelliJ IDEA. We want to build on this and provide even more functionality that is specific for Ktor, such as endpoint view, allowing you to get a better overview of the application architecture, helpers for creating plugins, and of course swagger support inline with our support for Swagger.
Documentation
We’re still continuing to work on documentation. We now provide both the current release version as well as the next EAP version. In addition we have plans to review and update our API docs to make these more descriptive.
Release Lifecycle
The release lifecycle will still remain the same. We still plan on releasing monthly patches, and committed to one major and several minor releases per year.
The above is what we’ll be working on in the short term. We’ll keep you updated!
