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
