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