Hi Chia-ping, Thank you for your feedback. I've updated the KIP and also added an explanation for why the client bridge version starts at 3.4 - "In 4.0.0, the most recent removed deprecated APIs were from 3.3.0, so the bridge version starts from 3.4."
Best, Kuan-Po Tseng On 2025/03/04 10:53:48 Chia-Ping Tsai wrote: > hi Kuan-Po > Q1: > in the "Kafka Connect:" section, the word "clients" should be replaced by > "connect", right? > > Q2: > Additionally, could you add a brief description explaining why the bridge > version used by Connect is "3.8.x - 3.9.x"? This conflicts with the "API > compatibility" section. > > Best, > Chia-Ping > > > > Kuan Po Tseng <brandb...@apache.org> 於 2025年3月4日 週二 上午9:35寫道： > > > Hello everyone, > > > > Thank you for the discussion. As we’ve previously mentioned, the > > deprecation rule would be better addressed in a separate KIP for greater > > visibility, allowing other developers to participate in that discussion. > > I’d like to keep KIP-1124 focused solely on the upgrade path without > > introducing additional concepts. > > > > Regarding Connect, I propose leaving it as it is. I’ve added a Connect > > section to the KIP, which is largely similar to the client section. The > > only notable difference is the bridge version range—since we’ve removed a > > deprecated API from 3.7, the appropriate bridge version from an API > > compatibility perspective should be [3.8.x–3.9.x]. > > > > Best, > > Kuan-Po Tseng > > > > On 2025/03/04 00:44:47 Chia-Ping Tsai wrote: > > > 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 > > > > > >
