Hi, I think we're discussing two separate things and each has a very different cost and benefit:
1. Having a longer support period for the last minor release: major releases happen pretty rarely and have breaking changes. It seems reasonable to consider improving how this case is handled. And it will be especially important for the upcoming AK 4.0 where support for ZooKeeper will be removed. That said, 24 months is a very long time for an open source project - it would divert resources away from innovation. 2. Having a longer support period for any minor release: Apache Kafka maintains compatibility across minor releases and it would be very expensive to maintain each of them (we have one every 4 months) for 12 months. The cost vs benefit for this one doesn't add up for me. Ismael On Thu, Apr 13, 2023 at 6:02 AM Divij Vaidya <divijvaidy...@gmail.com> wrote: > 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 >
