Thanks.

I am not a Connect expert, but the new section makes sense to me.


-Matthias

On 3/4/25 3:10 AM, Kuan Po Tseng wrote:
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




Reply via email to