Hi Chia-Ping, Sorry for the delayed response. I’ve checked all relevant JIRAs using the following Jira Query Language:
project = KAFKA AND status in (Resolved, Closed) AND fixVersion = 4.0.0 AND text ~ "Remove" order by updated DESC Based on this, I checked the JIRAs related to removing deprecated methods in client modules. The minimum backward-compatible client versions for client 4.0 are as follows: - Producer: 3.3.0 Reason: Partitioner#onNewBatch was deprecated in 3.3.0, and was removed by https://issues.apache.org/jira/browse/KAFKA-18295 - Consumer: 2.4.0 Reason: Consumer#committed was deprecated in 2.4.0, and was removed by https://issues.apache.org/jira/browse/KAFKA-17451 - Admin: 3.3.0 Reason: ListConsumerGroupOffsetsOptions was deprecated in 3.3.0 and was removed by https://issues.apache.org/jira/browse/KAFKA-18291 You can find a list of all related JIRAs and pull requests in this Google Sheet: https://docs.google.com/spreadsheets/d/1ZWNRk1rjWptjpGM2UtT0Q3lDULhrqkP_UfHr9roQW3M/edit?usp=sharing There are also some public methods removed in 4.0, such as: - KafkaFuture#Function, KafkaFuture#thenApply https://issues.apache.org/jira/browse/KAFKA-17903 - JmxReported(String) https://issues.apache.org/jira/browse/KAFKA-18077 , but I'm uncertain about how we should handle these. Best, Kuan-Po On 2025/02/06 19:08:49 Chia-Ping Tsai wrote: > hi Kuan-Po > > any update? Now that an upgrade path for bridge versions exists, we can > introduce additional "conditions" to assist users in selecting the "best" > bridge version. For example, we can provide guidance on which bridge versions > offer backward compatibility with Kafka 4.0 client or are compatible with > Kafka 4.0 server. > > Best, > Chia-Ping > > On 2025/01/22 04:48:36 Chia-Ping Tsai wrote: > > > - If we support 2.0+ to 4.0 client/KS upgrade it's simpler, but of course > > > brokers cannot be 4.0 yet -- but I guess this would be something natural? > > > Given that the clients would be on 2.0, brokers cannot be 4.0 yet, or > > > clients would have crashed already... Thus, I think I slightly prefer > > > this one. > > > > Using a major version as a bridge is a viable approach. We can emphasize > > the limitations of this method to guide users in selecting the most > > suitable bridge version. > > > > > For KS, from an API compatibility POV, upgrading from anything older than > > > 3.6 might not work any longer (for DSL users; of course, depending on > > > what APIs they are using). And for PAPI, the old API was removed too, so > > > only if the new one is use (introduced in 2.7) a seamless upgrade would > > > work smoothly. > > > > You make a valid point. The previous discussion overlooked the APIs that > > were removed in version 4.0. > > > > We could also emphasize the BC advantages. As an example, users have the > > option of using version 2.7 as a bridge and subsequently upgrade without > > code alterations or recompilation. Of course, we need to check the version > > of other PAPI removal. > > > > Best, > > Chia-Ping > > > > > > > > > > > > > Matthias J. Sax <mj...@apache.org> 於 2025年1月22日 凌晨2:55 寫道： > > > For KS, from an API compatibility POV, upgrading from anything older than > > > 3.6 might not work any longer (for DSL users; of course, depending on > > > what APIs they are using). And for PAPI, the old API was removed too, so > > > only if the new one is use (introduced in 2.7) a seamless upgrade would > > > work smoothly. > > >
