[
https://issues.apache.org/jira/browse/KAFKA-12419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346277#comment-17346277
]
A. Sophie Blee-Goldman edited comment on KAFKA-12419 at 5/17/21, 5:08 PM:
--------------------------------------------------------------------------
[~josep.prat] as Bruno said, only APIs that have been deprecated for long
enough can be removed. For 3.0 the cutoff is deprecations in 2.5 or older.
But yes, we should absolutely have tickets for removal of any deprecated
methods, classes, etc. We usually try to file those tickets at the time of
deprecation, though many slip through. It would be awesome if you could help us
triage the remaining deprecations and create tickets to track their removal.
Just verify that there isn't already an existing ticket. Bonus points if you
can figure out when they were deprecated and fill in the "Fix Version"
appropriately – I guess 4.0 is ok for anything that was deprecated more
recently than 2.5, if we end up doing 4.0 too soon to remove some of those then
we can re-triage those and figure out which will need to go up to 5.0. But
don't worry too much about looking up the deprecation version for each one,
just filing the tickets is helpful enough :)
Thanks!
was (Author: ableegoldman):
[~josep.prat] as Bruno said, only APIs that have been deprecated for long
enough can be removed. For 3.0 the cutoff is deprecations in 2.5 or older.
But yes, we should absolutely have tickets for removal of any deprecated
methods, classes, etc. We usually try to file those tickets at the time of
deprecation, though many slip through. It would be awesome if you could help us
triage the remaining deprecations and create tickets to track their removal.
Just verify that there isn't already an existing ticket. Bonus points if you
can figure out when they were deprecated and fill in the "Fix Version"
appropriately (I guess 4.0 is ok for anything that was deprecated more recently
than 2.5, if we end up doing 4.0 too soon to remove some of those then we can
re-triage those and figure out which will need to go up to 5.0
Thanks!
> Remove Deprecated APIs of Kafka Streams in 3.0
> ----------------------------------------------
>
> Key: KAFKA-12419
> URL: https://issues.apache.org/jira/browse/KAFKA-12419
> Project: Kafka
> Issue Type: Improvement
> Components: streams, streams-test-utils
> Reporter: Guozhang Wang
> Assignee: Tomasz Nguyen
> Priority: Blocker
> Labels: needs-kip
> Fix For: 3.0.0
>
>
> Here's a list of deprecated APIs that we have accumulated in the past, we can
> consider removing them in 3.0:
> * KIP-198: "--zookeeper" flag from StreamsResetter (1.0)
> * KIP-171: "–execute" flag from StreamsResetter (1.1)
> * KIP-233: overloaded "StreamsBuilder#addGlobalStore" (1.1)
> * KIP-251: overloaded "ProcessorContext#forward" (2.0)
> * KIP-276: "StreamsConfig#getConsumerConfig" (2.0)
> * KIP-319: "WindowBytesStoreSupplier#segments" (2.1)
> * KIP-321: "TopologyDescription.Source#topics" (2.1)
> * KIP-328: "Windows#until/segmentInterval/maintainMS" (2.1)
> * KIP-358: "Windows/Materialized" overloaded functions with `long` (2.1)
> * KIP-365/366: Implicit Scala Apis (2.1)
> * KIP-372: overloaded "KStream#groupBy" (2.1)
> * KIP-307: "Joined#named" (2.3)
> * KIP-345: Broker config "group.initial.rebalance.delay.ms" (2.3)
> * KIP-429: "PartitionAssignor" interface (2.4)
> * KIP-470: "TopologyTestDriver#pipeInput" (2.4)
> * KIP-476: overloaded "KafkaClientSupplier#getAdminClient" (2.4)
> * KIP-479: overloaded "KStream#join" (2.4)
> * KIP-530: old "UsePreviousTimeOnInvalidTimeStamp" (2.5)
> * KIP-535 / 562: overloaded "KafkaStreams#metadataForKey" and
> "KafkaStreams#store" (2.5)
> And here's a list of already filed JIRAs for removing deprecated APIs
> * KAFKA-10434
> * KAFKA-7785
> * KAFKA-12796
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
