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 <mjsax@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
>>>
>>
>
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 <mjsax@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
>>>
>>
>
Comments
Post a Comment