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