Kea Roadmap Update

We have updated the Kea release plan in our Knowledgebase to show that we expect to issue new major versions approximately every year, and each one will be supported for two years.

The next stable version will be Kea 2.0

The next major branch will be called Kea 2.0, in recognition of the major architectural changes included, and it will be released in Q3 of 2021. Kea 2.0 will be our first stable version that is entirely multi-threaded; it will also be more secure, providing native HTTPS authentication for the API. Both of these features have required many smaller commits to develop, so users have seen the features appear in Kea 1.9 development versions, but we want to complete the implementations before we release the next branch. We know that many Kea users are eager to deploy these features in production as soon as possible.

We maintain a matrix showing significant features and when they were first introduced, which will be updated when we release Kea 2.0.

What is a stable version?

A stable version is one in which we minimize any potentially destabilizing changes. Generally, new features are not added, although in rare cases we backport a feature that current deployments need for improved stability or manageability. If changes need to be made to an existing feature, we try to find a way to maintain the pre-existing default behavior. Normally, we issue maintenance releases on a stable version only when there are significant bugs to address. If you don’t see any new minor versions, that is good news.

However, due to maintenance, it is possible that there may be changes to the REST API and/or the database schema in a minor release of a stable version. If you update from one version of Kea to another, even a minor version change, you will need to also update whatever Kea hooks you are using. We version-control the hooks along with the Kea versions, even if there is no change in the hook library itself.

We do not plan to add new operating system versions to the ISC packages for a stable version. When we produce a new stable version we assess the currently supported versions of our supported OSes and try to maintain those for the life of the stable branch. In the case of an operating system with very short lifecycles (e.g. Fedora), we may need to make an exception to this policy, for example if all supported OS versions go EOL during the life of the stable ISC branch.

Kea roadmap for new feature development

If you are interested in following updates to our development roadmap, you may view the monthly milestones we create in GitLab. When we begin work on a new milestone we create a list of issues we would like to address. This list is typically an ambitious goal, and nearly always there are some issues we don’t complete during the milestone that are then deferred to a later milestone. If there is an issue you are particularly interested in, you are welcome to upvote it or add a comment to that effect in our GitLab issue tracker.