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 > > >
