Hi folks The goal of this discussion is to re-visit the End Of Life (EOL) policy of Kafka and introduce a few changes to it.
*Current EOL policy* Kafka currently follows a time based release plan with an EOL policy documented here: https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy? *Limitations of current policy* The current EOL policy suffers from limitations such as: 1. It does not differentiate between support for bug fixes and support for security vulnerability fixes. This leads to confusion for the users as some CVEs <https://kafka.apache.org/cve-list> such as CVE-2023-25194 are only fixed in latest versions and others such as CVE-2022-34917 are fixed even in the previous major versions. 2. Users find it difficult to upgrade major versions within a span of a year. For example, 2.x to 3.x brought multiple changes. For such major upgrades, users require more time than 12 months to schedule resources for upgrade, change the configuration (since defaults have changed), ensure compatibility with tools and test for any performance changes. 3. Our current policy mentions both a time based and a version based support period. We should clarify and confirm whether the support policy is based on time or number of releases. *Kafka EOL policy* To overcome the above problems, I would like to propose the following changes to end of life policy. "Minor versions within the latest major version will be maintained with bug fix releases for a period of 12 months. For example, 3.3.x was first released in Feb 2023 and will receive bug fixes until Feb 2024. The bug fix release will be performed as-needed. Only security vulnerabilities and production-impacting bugs without workarounds are backported to previous minor versions. Missing features from latest releases are not backported by default. Exceptions are approved by Lazy Majority." Note that this is the same as current policy. "The last minor version within the previous major version will be maintained with bug fix releases for a period of 24 months. For example, 2.8.x was first released in Apr 2021 and will receive bug fixes until Apr 2022. The bug fix release will be performed as-needed. Only security vulnerabilities and production-impacting bugs without workarounds are added to bug fix versions." This is a new policy that provides users with 24 months (as compared to 12 months today) to upgrade their major version. "The last minor version within the previous major version will be maintained with security fixes for a period of 3 years. For example, 2.8.x was first released in Apr 2021 and will receive security fixes until Apr 2024." This is a new policy inspired from the concept of LTS releases in open source projects such as Java, Ubuntu and Linux Kernel. Apache projects such as Spark [1] follow this policy. *EOL policy of other projects* [1] Spark [https://spark.apache.org/versioning-policy.html] - Feature branches / minor versions are maintained with bug fixes for 18 months and major versions are maintained for 31 months. [2] Airflow [ https://airflow.apache.org/docs/apache-airflow/stable/installation/supported-versions.html#version-life-cycle] - 1 year support for each minor version. [3] Kubernetes [ https://kubernetes.io/releases/patch-releases/#support-period] - Minor versions are maintained for 14 months. [4] Flink [ https://flink.apache.org/downloads/#update-policy-for-old-releases] - Supports 2 minor versions with bug fixes. Mandates a patch release for minor versions going end of life. [5] Pulsar [https://pulsar.apache.org/contribute/release-policy/] - Different security and bug fix policy. Has a concept of LTS release. LTS receives bug fixes for 24 months and security fixes for 36 months. As our Bylaws <https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Approvals> don't mention the voting action required for changing EOL policy, I would propose a vote for this change by Lazy Majority <https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Approvals> . Thoughts? -- Divij Vaidya
