Dear all, Thank you for the discussion. Apologies for introducing an unrelated topic. Here's a summary of that discussion.
1. A new KIP or thread will be created to define a formal deprecation policy. This policy will apply to releases following 4.0, as 4.0 does not fully conform to it. 2. We will not revert the 4.0 code. KIP-1124 focuses on client and streams APIs, and the removed Connect REST API is outside its scope. If there are no objections to KIP-1124, please cast your vote in the voting thread. Additionally, I propose adding a 'Client Upgrade Path' section to the 4.0 documentation to highlight KIP-1124 if it passes. Thanks, Chia-Ping > Matthias J. Sax <mj...@apache.org> 於 2025年3月4日 凌晨1:57 寫道： > What Chia-Ping says. > > To me, if we remove it in 4.0, we did not really keep it for 1 year if > deprecated in 3.7, but it's subject to debate. At least for KS, we always > kept stuff of the last 3 releases. > > I agree, that KIP-1124 should focus on clients/streams, and we want to keep > the code as-is for 4.0 release, and remove these API in Connect, I have no > objections at all. > > Thus, the question is not really about KIP-1124 directly, but more about 4.0 > release in particular. > > Seems the verdict is, to keep the code as-is for 4.0 and remove these Connect > API with 4.0.0. Works for me. > > > -Matthias > > On 3/3/25 9:02 AM, Chia-Ping Tsai wrote: >>> So that's 3 releases (3.7, 3.8 and 3.9) and over 1 year, no? >> KIP-1124 highlights "we keep deprecated APIs for at least 3 prior >> versions," but the Connect API change does not follow this rule. It is >> valid if the deprecation happens in 3.6. >> Best, >> Chia-Ping >> Mickael Maison <mickael.mai...@gmail.com> 於 2025年3月4日 週二 上午12:40寫道： >>> Hi, >>> For the Connect REST API change, the deprecation is in 3.7.0 which >>> released in February 2024. So that's 3 releases (3.7, 3.8 and 3.9) and >>> over 1 year, no? >>> Mickael >>> On Mon, Mar 3, 2025 at 5:31 PM Chia-Ping Tsai <chia7...@gmail.com> wrote: >>>> hi all, >>>>> I am also happy to follow Ismael's proposal and say "at least 3 >>> releases >>>> _and_ a minimum of 12 months". >>>> +1 to this proposal >>>>> Another example is >>> https://github.com/apache/kafka/commit/a753172ad3e0927f412fb56e468c95a9a81ba3ad >>>> We deprecated our log4j1 appender in 3.8.0 and it's been removed in >>>> 4.0.0. Kafka 3.8.0 released in May 2024, so it's less than 1 year. >>>> Yes, that's also an exception. Fortunately, this "breaking" change >>> doesn't >>>> affect the client, Streams, or Connect update path >>>> I personally suggest creating a separate KIP to detail the new >>> deprecation >>>> rules (and create a new thread for this topic) . KIP-1124 only covers a >>>> portion of deprecation issues, specifically API compatibility for >>> clients, >>>> Streams, and Connect. As Mickael mentioned, 4.0 cannot fully comply with >>>> the new deprecation rules across the entire project. KIP-1124 should >>> focus >>>> on reaching consensus regarding the consistency we can achieve in 4.0. >>>> Best, >>>> Chia-Ping >>>> Matthias J. Sax <mj...@apache.org> 於 2025年3月4日 週二 上午12:25寫道： >>>>> Thanks Mickeal, >>>>> I guess the question is, if we think we need to revert these removals, >>>>> or if it's more reasonable to make an exception from the rule? >>>>> I cannot really judge it, as I am not familiar with the details for >>>>> Connect. Any suggestions from your side? >>>>> -Matthias >>>>> On 3/3/25 7:44 AM, Mickael Maison wrote: >>>>>> Hi, >>>>>> Another example is >>> https://github.com/apache/kafka/commit/a753172ad3e0927f412fb56e468c95a9a81ba3ad >>>>>> We deprecated our log4j1 appender in 3.8.0 and it's been removed in >>>>>> 4.0.0. Kafka 3.8.0 released in May 2024, so it's less than 1 year. >>>>>> Thanks, >>>>>> Mickael >>>>>> On Mon, Mar 3, 2025 at 4:40 PM Matthias J. Sax <mj...@apache.org> >>> wrote: >>>>>>> From >>> https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan >>>>>>>> We break compatibility (i.e. remove deprecated public methods >>> after a >>>>> reasonable period, and typically wait 1 year after deprecation). >>>>>>> To me, given that we do 3 releases per year, "1 year" as stated >>> above >>>>>>> and 3 releases, is just the same thing. >>>>>>> I am also happy to follow Ismael's proposal and say "at least 3 >>> releases >>>>>>> _and_ a minimum of 12 months". >>>>>>> -Matthias >>>>>>> On 3/3/25 6:48 AM, Ismael Juma wrote: >>>>>>>> Hi Chia-Ping and Bruno, >>>>>>>> Right. Matthias stated that the 3 releases rule is the source of >>> truth >>>>> and >>>>>>>> I don't recall that being the case. The source of truth is 12 >>> months - >>>>> I >>>>>>>> was one of the people who was part of that discussion when the >>> Scala >>>>>>>> consumer was removed. I also disagree that the 3 releases rule is >>>>> strictly >>>>>>>> better since we can sometimes have shorter release cycles (like the >>>>> intent >>>>>>>> with the 3.9 release). I am ok with adjusting the rule to be "at >>> least >>>>> 3 >>>>>>>> releases _and_ a minimum of 12 months" as part of this KIP, but we >>>>> should >>>>>>>> be clear that we're proposing a change as part of this KIP (vs >>>>> following an >>>>>>>> existing rule). >>>>>>>> Ismael >>>>>>>> On Mon, Mar 3, 2025 at 1:24 AM Bruno Cadonna <cado...@apache.org> >>>>> wrote: >>>>>>>>> Hi, >>>>>>>>> I suspect that the three-release-rule was a derivation from the >>>>>>>>> 1-year-rule since we usually have three releases in one year. >>>>>>>>> IMO, a three-release rule is easier to reason about, because you >>> don't >>>>>>>>> need to know when the release took place. >>>>>>>>> However, I recognize that the 1-year-rule seems to be the official >>>>> rule. >>>>>>>>> Best, >>>>>>>>> Bruno >>>>>>>>> On 03.03.25 09:58, Chia-Ping Tsai wrote: >>>>>>>>>> hi Ismael >>>>>>>>>> The thread[0] contains a brief discussion about the one-year >>> rule. >>>>> I've >>>>>>>>>> also updated the KIP page[1] to highlight this rule. However, >>>>> declaring >>>>>>>>>> [3.7-3.9] as API compatible with 4.0 can be unrelated to the >>> one-year >>>>>>>>> rule. >>>>>>>>>> We can do this for consistency, ensuring clients, Streams, and >>>>> Connect >>>>>>>>> have >>>>>>>>>> the same version range. Additionally, we can address this by >>>>> reverting a >>>>>>>>>> minor commit. If we don't agree on consistency, we can update the >>>>> KIP to >>>>>>>>>> include different API compatibility versions for Connect. >>>>>>>>>> [0] >>> https://lists.apache.org/thread/j7n4qqsvxz84f5cg89kdm9foby36j28n >>>>>>>>>> [1] >>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=65867320&selectedPageVersions=9&selectedPageVersions=8 >>>>>>>>>> Best, >>>>>>>>>> Chia-Ping
