You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Divij Vaidya <di...@gmail.com> on 2023/04/13 13:01:02 UTC
[DISCUSS] Re-visit end of life policy
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
Re: [DISCUSS] Re-visit end of life policy
Posted by Divij Vaidya <di...@gmail.com>.
Regarding#2 - About the support of minor versions:
Fair enough. We can keep the current policy for latest minor versions until
we can reduce the effort it requires to release a version.
Regarding#1 - About the last major version release:
About backporting security patches to the latest minor version within the
previous major version, I believe that the trade-off of extra maintenance
for last minor version overhead for 24 months is worth it. As a data point,
based on usage of kafka-clients package in maven, majority of users are
still using 2.x Kafka even after
My questions to you (and the community) are:
1. If not 24 months, what is the recommendation on security support for the
last minor version within the previous major/LTS version? IMO, the current
12 months is too less for users to perform a major version upgrade.
2. What needs to happen to support a longer EOL for the major/LTS version?
Some ideas are having folks commit to being release manager in advance of 6
months, open up release management duty to non-committers as well (where
committers can act as release shepherds), increase the number of active
committers in proportion to the amount of committer work required in the
community etc.
--
Divij Vaidya
On Thu, Apr 13, 2023 at 11:53 PM Ismael Juma <is...@juma.me.uk> wrote:
> Clarification below.
>
> I did not understand your point about maintenance expense to ensure
> > compatibility. I am confused because, IMO, irrespective of our bug fix
> > support duration for minor versions, we should ensure that all prior
> minor
> > versions are compatible. Hence, increasing the support duration to 24
> > months will not add more expense than today to ensure compatibility.
> >
>
> No, I am not saying that. I am saying that there is no reason not to
> upgrade from one minor release to another since we provide full
> compatibility between minor releases. The expensive part is that we release
> 3 times a year, so you have to support 6 releases at any given point in
> time. More importantly, you have to validate all these releases, handle any
> additional bugs and so on. When it comes to the CVE stuff, you also have to
> deal with cases where a project you depend on forces an upgrade to a
> release with compatibility impact and so on. Having seen this first hand,
> it's a significant amount of work.
>
> Ismael
>
Re: [DISCUSS] Re-visit end of life policy
Posted by Colin McCabe <cm...@apache.org>.
Ultimately, maintaining both the ZK-based controller and the KRaft-based controller takes a substantial resource toll on the community. That's the reason why we agreed to drop the ZK based controller in Apache Kafka 4.0, as part of KIP-833.
If there is a serious bug in the last bridge release, we could certainly consider fixing it even if the EOL period is past for that release. But I think that's pretty unlikely and we can discuss it if and when it comes up.
We've done everything we can to ensure compatibility with existing users, even to the point of re-adding the same bugs that ZK mode had in some cases. We've also put in a lot of work to ensure that migration will not involve any downtime.
If there is something broken then let's fix the broken thing and move forward, just as we've always done. And just as Kafka system administrators have always done.
best,
Colin
On Tue, May 16, 2023, at 09:29, Igor Soarez wrote:
> My impression is also that a lot of users run older,
> out of EOL, versions of Kafka.
>
> The final 3.x version is particularly concerning, as it will be
> the last bridge to migrate away from ZK. If a big portion of users
> only upgrade after its EOL period, we might only then discover an
> important bug and potentially be cutting off the migration path (or
> just making it really difficult) for a lot of users.
>
> Could the release efforts be re-shuffled perhaps to allow a longer
> bug fix policy for the last minor release in each release version?
> Or does the KRaft migration perhaps merit an exceptional case?
>
> --
> Igor
Re: [DISCUSS] Re-visit end of life policy
Posted by Igor Soarez <so...@apple.com.INVALID>.
My impression is also that a lot of users run older,
out of EOL, versions of Kafka.
The final 3.x version is particularly concerning, as it will be
the last bridge to migrate away from ZK. If a big portion of users
only upgrade after its EOL period, we might only then discover an
important bug and potentially be cutting off the migration path (or
just making it really difficult) for a lot of users.
Could the release efforts be re-shuffled perhaps to allow a longer
bug fix policy for the last minor release in each release version?
Or does the KRaft migration perhaps merit an exceptional case?
--
Igor
Re: [DISCUSS] Re-visit end of life policy
Posted by "Matthias J. Sax" <mj...@apache.org>.
Adding the user-mailing list. Seems relevant to everybody.
On 4/20/23 2:45 AM, Divij Vaidya wrote:
> Thank you Matthias for your comments.
>
> I agree with you that the decision should be driven based on strong
> community ask as it introduces a significant overhead on the maintainers. I
> was hoping that more folks (users of Kafka) would contribute to this thread
> with their opinion but perhaps, I need to find alternative ways to get data
> about Kafka version usage in the wild. Given the effort of migrating major
> versions (2.x to 3.x), I am actually surprised that we don't hear more
> often from the users about the community's 12 month EOL policy.
>
> I will get back on this thread once I have more data to support the
> proposal.
>
> --
> Divij Vaidya
>
>
>
> On Thu, Apr 20, 2023 at 3:52 AM Matthias J. Sax <mj...@apache.org> wrote:
>
>> While I understand the desire, I tend to agree with Ismael.
>>
>> In general, it's a significant amount of work not just to do the actual
>> releases, but also the cherry-pick bug-fixed to older branches. Code
>> diverges very quickly, and a clean cherry-pick is usually only possible
>> for one or two branches. And it's not just simple conflicts that are
>> easy to resolve, but it often even implies to do a full new fix, if the
>> corresponding code was refactored, what is more often the case than one
>> might think.
>>
>> If there is no very strong ask from the community, I would rather let
>> committer spent their time reviewing PRs instead and help contributors
>> to get the work merged.
>>
>> Just my 2ct.
>>
>> -Matthias
>>
>>
>> On 4/13/23 2:52 PM, Ismael Juma wrote:
>>> Clarification below.
>>>
>>> I did not understand your point about maintenance expense to ensure
>>>> compatibility. I am confused because, IMO, irrespective of our bug fix
>>>> support duration for minor versions, we should ensure that all prior
>> minor
>>>> versions are compatible. Hence, increasing the support duration to 24
>>>> months will not add more expense than today to ensure compatibility.
>>>>
>>>
>>> No, I am not saying that. I am saying that there is no reason not to
>>> upgrade from one minor release to another since we provide full
>>> compatibility between minor releases. The expensive part is that we
>> release
>>> 3 times a year, so you have to support 6 releases at any given point in
>>> time. More importantly, you have to validate all these releases, handle
>> any
>>> additional bugs and so on. When it comes to the CVE stuff, you also have
>> to
>>> deal with cases where a project you depend on forces an upgrade to a
>>> release with compatibility impact and so on. Having seen this first hand,
>>> it's a significant amount of work.
>>>
>>> Ismael
>>>
>>
>
Re: [DISCUSS] Re-visit end of life policy
Posted by "Matthias J. Sax" <mj...@apache.org>.
Adding the user-mailing list. Seems relevant to everybody.
On 4/20/23 2:45 AM, Divij Vaidya wrote:
> Thank you Matthias for your comments.
>
> I agree with you that the decision should be driven based on strong
> community ask as it introduces a significant overhead on the maintainers. I
> was hoping that more folks (users of Kafka) would contribute to this thread
> with their opinion but perhaps, I need to find alternative ways to get data
> about Kafka version usage in the wild. Given the effort of migrating major
> versions (2.x to 3.x), I am actually surprised that we don't hear more
> often from the users about the community's 12 month EOL policy.
>
> I will get back on this thread once I have more data to support the
> proposal.
>
> --
> Divij Vaidya
>
>
>
> On Thu, Apr 20, 2023 at 3:52 AM Matthias J. Sax <mj...@apache.org> wrote:
>
>> While I understand the desire, I tend to agree with Ismael.
>>
>> In general, it's a significant amount of work not just to do the actual
>> releases, but also the cherry-pick bug-fixed to older branches. Code
>> diverges very quickly, and a clean cherry-pick is usually only possible
>> for one or two branches. And it's not just simple conflicts that are
>> easy to resolve, but it often even implies to do a full new fix, if the
>> corresponding code was refactored, what is more often the case than one
>> might think.
>>
>> If there is no very strong ask from the community, I would rather let
>> committer spent their time reviewing PRs instead and help contributors
>> to get the work merged.
>>
>> Just my 2ct.
>>
>> -Matthias
>>
>>
>> On 4/13/23 2:52 PM, Ismael Juma wrote:
>>> Clarification below.
>>>
>>> I did not understand your point about maintenance expense to ensure
>>>> compatibility. I am confused because, IMO, irrespective of our bug fix
>>>> support duration for minor versions, we should ensure that all prior
>> minor
>>>> versions are compatible. Hence, increasing the support duration to 24
>>>> months will not add more expense than today to ensure compatibility.
>>>>
>>>
>>> No, I am not saying that. I am saying that there is no reason not to
>>> upgrade from one minor release to another since we provide full
>>> compatibility between minor releases. The expensive part is that we
>> release
>>> 3 times a year, so you have to support 6 releases at any given point in
>>> time. More importantly, you have to validate all these releases, handle
>> any
>>> additional bugs and so on. When it comes to the CVE stuff, you also have
>> to
>>> deal with cases where a project you depend on forces an upgrade to a
>>> release with compatibility impact and so on. Having seen this first hand,
>>> it's a significant amount of work.
>>>
>>> Ismael
>>>
>>
>
Re: [DISCUSS] Re-visit end of life policy
Posted by Divij Vaidya <di...@gmail.com>.
Thank you Matthias for your comments.
I agree with you that the decision should be driven based on strong
community ask as it introduces a significant overhead on the maintainers. I
was hoping that more folks (users of Kafka) would contribute to this thread
with their opinion but perhaps, I need to find alternative ways to get data
about Kafka version usage in the wild. Given the effort of migrating major
versions (2.x to 3.x), I am actually surprised that we don't hear more
often from the users about the community's 12 month EOL policy.
I will get back on this thread once I have more data to support the
proposal.
--
Divij Vaidya
On Thu, Apr 20, 2023 at 3:52 AM Matthias J. Sax <mj...@apache.org> wrote:
> While I understand the desire, I tend to agree with Ismael.
>
> In general, it's a significant amount of work not just to do the actual
> releases, but also the cherry-pick bug-fixed to older branches. Code
> diverges very quickly, and a clean cherry-pick is usually only possible
> for one or two branches. And it's not just simple conflicts that are
> easy to resolve, but it often even implies to do a full new fix, if the
> corresponding code was refactored, what is more often the case than one
> might think.
>
> If there is no very strong ask from the community, I would rather let
> committer spent their time reviewing PRs instead and help contributors
> to get the work merged.
>
> Just my 2ct.
>
> -Matthias
>
>
> On 4/13/23 2:52 PM, Ismael Juma wrote:
> > Clarification below.
> >
> > I did not understand your point about maintenance expense to ensure
> >> compatibility. I am confused because, IMO, irrespective of our bug fix
> >> support duration for minor versions, we should ensure that all prior
> minor
> >> versions are compatible. Hence, increasing the support duration to 24
> >> months will not add more expense than today to ensure compatibility.
> >>
> >
> > No, I am not saying that. I am saying that there is no reason not to
> > upgrade from one minor release to another since we provide full
> > compatibility between minor releases. The expensive part is that we
> release
> > 3 times a year, so you have to support 6 releases at any given point in
> > time. More importantly, you have to validate all these releases, handle
> any
> > additional bugs and so on. When it comes to the CVE stuff, you also have
> to
> > deal with cases where a project you depend on forces an upgrade to a
> > release with compatibility impact and so on. Having seen this first hand,
> > it's a significant amount of work.
> >
> > Ismael
> >
>
Re: [DISCUSS] Re-visit end of life policy
Posted by "Matthias J. Sax" <mj...@apache.org>.
While I understand the desire, I tend to agree with Ismael.
In general, it's a significant amount of work not just to do the actual
releases, but also the cherry-pick bug-fixed to older branches. Code
diverges very quickly, and a clean cherry-pick is usually only possible
for one or two branches. And it's not just simple conflicts that are
easy to resolve, but it often even implies to do a full new fix, if the
corresponding code was refactored, what is more often the case than one
might think.
If there is no very strong ask from the community, I would rather let
committer spent their time reviewing PRs instead and help contributors
to get the work merged.
Just my 2ct.
-Matthias
On 4/13/23 2:52 PM, Ismael Juma wrote:
> Clarification below.
>
> I did not understand your point about maintenance expense to ensure
>> compatibility. I am confused because, IMO, irrespective of our bug fix
>> support duration for minor versions, we should ensure that all prior minor
>> versions are compatible. Hence, increasing the support duration to 24
>> months will not add more expense than today to ensure compatibility.
>>
>
> No, I am not saying that. I am saying that there is no reason not to
> upgrade from one minor release to another since we provide full
> compatibility between minor releases. The expensive part is that we release
> 3 times a year, so you have to support 6 releases at any given point in
> time. More importantly, you have to validate all these releases, handle any
> additional bugs and so on. When it comes to the CVE stuff, you also have to
> deal with cases where a project you depend on forces an upgrade to a
> release with compatibility impact and so on. Having seen this first hand,
> it's a significant amount of work.
>
> Ismael
>
Re: [DISCUSS] Re-visit end of life policy
Posted by Ismael Juma <is...@juma.me.uk>.
Clarification below.
I did not understand your point about maintenance expense to ensure
> compatibility. I am confused because, IMO, irrespective of our bug fix
> support duration for minor versions, we should ensure that all prior minor
> versions are compatible. Hence, increasing the support duration to 24
> months will not add more expense than today to ensure compatibility.
>
No, I am not saying that. I am saying that there is no reason not to
upgrade from one minor release to another since we provide full
compatibility between minor releases. The expensive part is that we release
3 times a year, so you have to support 6 releases at any given point in
time. More importantly, you have to validate all these releases, handle any
additional bugs and so on. When it comes to the CVE stuff, you also have to
deal with cases where a project you depend on forces an upgrade to a
release with compatibility impact and so on. Having seen this first hand,
it's a significant amount of work.
Ismael
Re: [DISCUSS] Re-visit end of life policy
Posted by Divij Vaidya <di...@gmail.com>.
Thank you for your comments, Ismael.
1. About the last major version release: There is precedence in open
source projects such as Spark, Pulsar etc. that are already offering a
LTS/major version support with longer support duration than Kafka. If we
limit our support to include production impacting bugs with no workaround,
do you still think that we will have to invest
2. About the support of minor versions:
2.1 - Just to make sure that we are on the same page, the cost we are
talking about is the engineering effort required to backport changes and
perform a release. Is there anything else that I am missing? If yes, is
that cost acceptable in future as we increase our number of committers?
2.2 - We ensure compatibility (this is another thing that we should
formalize and document) amongst all minor versions within a major version.
I did not understand your point about maintenance expense to ensure
compatibility. I am confused because, IMO, irrespective of our bug fix
support duration for minor versions, we should ensure that all prior minor
versions are compatible. Hence, increasing the support duration to 24
months will not add more expense than today to ensure compatibility.
Apart from the above points, Ismael, what do you think about having
different durations of security support and bug fix support?
--
Divij Vaidya
On Thu, Apr 13, 2023 at 4:13 PM Ismael Juma <is...@juma.me.uk> wrote:
> 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 <di...@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
> >
>
Re: [DISCUSS] Re-visit end of life policy
Posted by Ismael Juma <is...@juma.me.uk>.
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 <di...@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
>