This document describes how KEDA handles versioning, releases new versions and communicates about them.
KEDA uses semantic versioning so that their users can reliably upgrade according to their needs.
You can learn about our roadmap and upcoming releases here.
You can learn about our release process here.
We provide a changelog that includes every change per version must be available as part of the repo, for example, here is the changelog for KEDA Core.
Next to that, every closed issue and PR should be added to a GitHub Milestone that provides an overview of everything that will be included and provide an indication of what the current intended release date is. However, the release date is subject to change and only provides an indication.
Lastly, every new release will come with a GitHub Release which provides the exact changelog for that release.
If you want to be notified of new releases, we recommend watching our KEDA Core repository on GitHub and ensure you are subscribing for releases.
Next to that, you can join the conversation for every new release on GitHub Discussions.
Every new major version, KEDA maintainers are allowed to remove features or make breaking changes as per semantic versioning.
Along with such a release there will always be a migration guide to provide an overview of what has changed, what the impact is and how to migrate. Here is an example of our v1.x to v2.0 migration guide (example).
For every one of these, KEDA will always announce a deprecation notice on GitHub Discussions that provides context on why it is changing, what the impact is, when it will change and what steps that are required to be taken.
In majority of the cases, we will allow you to already migrate in the next minor version where we introduce the deprecation so that you can migrate fast.
Learn more about our support policy here.