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

Reply via email to