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.
> > > >
> > >
> >
>

Reply via email to