Hello all, sorry a bit late, just minor comments on this one: - Should we clarify in the title or at the beginning of the KIP that it is proposing a client upgrade path for 4.x? The broader considerations for upgrades discussed in this thread will be tackled separately (seems we all agree).
- The KS upgrade path seems to be the tricky one, and all that the user needs to consider to successfully follow the provided path for KS is not clear in the KIP, but it's all well explained on the KS upgrade notes for 3.9, should we add a ref to that? https://kafka.apache.org/39/documentation/streams/upgrade-guide Thanks Kuan Po! Lianet On Tue, Feb 11, 2025 at 11:22 AM Kuan Po Tseng <brandb...@gmail.com> wrote: > Hello everyone, > > If there are no other opinions, I would like to start a vote tomorrow, > thank you! > > Best, > Kuan Po > > On Sat, Feb 8, 2025 at 1:51 AM Kuan Po Tseng <brandb...@apache.org> wrote: > > > Hi all, > > > > Based on our discussion, I added a section on choosing the appropriate > > bridge version from an API compatibility perspective for upgrading to > Kafka > > 4.0. Let me know if you have any thoughts. Thank you! > > > > Best, > > Kuan-Po > > > > On 2025/02/07 03:34:46 Kuan Po Tseng wrote: > > > 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. > > > > > > > > > > > > > > >
