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
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.
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, M
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 remo
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 wrote:
>
> hi all,
>
> > I am also happy to follow Ismael's proposal and say "at l
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 r
Matthias J. Sax created KAFKA-18913:
---
Summary: Consider removing state-updater feature flag
Key: KAFKA-18913
URL: https://issues.apache.org/jira/browse/KAFKA-18913
Project: Kafka
Issue Type
[
https://issues.apache.org/jira/browse/KAFKA-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Cadonna reopened KAFKA-18067:
---
We had to revert the fix for this bug
(https://github.com/apache/kafka/pull/19078) because it i
Hi Bruno,
Please go ahead and cherry-pick it to 4.0.
Best,
David
On Mon, Mar 3, 2025 at 10:12 AM Bruno Cadonna wrote:
>
> Hi David,
>
> we found an issue with Kafka Streams that definitely is a regression. A
> commit fixed a leak, introduced a bug that prevented Kafka Streams from
> re-initiali
Hi David,
we found an issue with Kafka Streams that definitely is a regression. A
commit fixed a leak, introduced a bug that prevented Kafka Streams from
re-initializing its transactional producer in case the producer is
fenced. The consequence of not re-initializing the transactional
produce
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
Luke Chen created KAFKA-18911:
-
Summary: alterPartition gets stuck when getting out-of-date errors
Key: KAFKA-18911
URL: https://issues.apache.org/jira/browse/KAFKA-18911
Project: Kafka
Issue Typ
[
https://issues.apache.org/jira/browse/KAFKA-18911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Chen resolved KAFKA-18911.
---
Resolution: Invalid
> alterPartition gets stuck when getting out-of-date errors
> --
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 Conne
Lorcan created KAFKA-18912:
--
Summary: Failed test
MetadataSchemaCheckerToolTest.testVerifyEvolutionGit on Trunk
Key: KAFKA-18912
URL: https://issues.apache.org/jira/browse/KAFKA-18912
Project: Kafka
Hi Jun,
Thanks. I have cherry-picked
https://issues.apache.org/jira/browse/KAFKA-18864 to 4.0.
Best,
David
On Mon, Mar 3, 2025 at 3:18 PM David Jacot wrote:
> Hi all,
>
> I have opened https://github.com/apache/kafka/pull/19080 for Kirk's
> logging observation.
>
> Best,
> David
>
> On Mon, Ma
Hi all,
I have opened https://github.com/apache/kafka/pull/19080 for Kirk's logging
observation.
Best,
David
On Mon, Mar 3, 2025 at 12:22 PM David Jacot wrote:
> Hi Bruno,
>
> Please go ahead and cherry-pick it to 4.0.
>
> Best,
> David
>
> On Mon, Mar 3, 2025 at 10:12 AM Bruno Cadonna wrote:
Hi, Ismael,
I want to start a followup discussion on the following update in the KIP.
"Finally, we will fix a protocol specification inconsistency: FetchResponse
has a records field that is tagged as nullable even though it is always
non-null and all librdkafka-based clients (which cover a lar
[
https://issues.apache.org/jira/browse/KAFKA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao resolved KAFKA-18844.
-
Resolution: Fixed
The PR is merged to trunk, 4.0 and 3.9.
> Stale features information in QuorumControl
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
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
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
> 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 於 2025年3月4日 週二 上午12:40寫
[
https://issues.apache.org/jira/browse/KAFKA-18867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved KAFKA-18867.
Fix Version/s: 4.1.0
Resolution: Fixed
> add tests to describe topic configs with e
Chia-Ping Tsai created KAFKA-18915:
--
Summary: Migrate AdminClientRebootstrapTest to use new test infra
Key: KAFKA-18915
URL: https://issues.apache.org/jira/browse/KAFKA-18915
Project: Kafka
Chia-Ping Tsai created KAFKA-18914:
--
Summary: Migrate ConsumerRebootstrapTest to use new test infra
Key: KAFKA-18914
URL: https://issues.apache.org/jira/browse/KAFKA-18914
Project: Kafka
Iss
[
https://issues.apache.org/jira/browse/KAFKA-18878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Apoorv Mittal resolved KAFKA-18878.
---
Fix Version/s: 4.1.0
Resolution: Fixed
> Implement ShareSessionCache and DelayedShare
27 matches
Mail list logo
