Thanks for updating the KIP. A comment below: As we introduce this change in major version 4.1.0, since we provide the > backend binding dependencies, users should be able to upgrade their backend > dependencies.
4.1 is a minor version (not major version). So, this KIP is only acceptable in 4.1.0 if we can ensure it doesn't break existing users. Otherwise, it has to wait for 5.0.0. Can you please clarify the KIP with this additional context? Ismael On Sun, Mar 9, 2025 at 8:42 PM TengYao Chi <kiting...@gmail.com> wrote: > Hello guys, > I have taken over this KIP from Muralidhar. > Given that the original content is outdated since the logging framework has > been widely changed, I have updated the content of the KIP. > Please take a look and share your thoughts. > > Best Regards, > TengYao > > TengYao Chi <kiting...@gmail.com> 於 2025年2月23日 週日 下午3:19寫道： > > > Hi Muralidhar, > > > > Thanks for the KIP. > > Since we have migrated to log4j2, the KIP content must also be updated. > > > > Best Regards, > > TengYao > > > > > > Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 2024年9月10日 週二 > > 下午1:21寫道： > > > >> Hi, > >> > >> I assume there are no concerns. Will start a voting thread. > >> > >> Thanks, > >> Murali > >> > >> On Fri, Sep 6, 2024 at 2:45 PM Muralidhar Basani < > >> muralidhar.bas...@aiven.io> > >> wrote: > >> > >> > Hi all, > >> > > >> > Now that we are close to 4.0, bringing up this discussion again. > >> > > >> > Do we want to include any other providers, and as for now we have only > >> > reload4j binding in our dependencies. > >> > We can always provide support for others later. > >> > > >> > Mainly upgrading slf4j to 2.x in 4.0.0 is a primary motive for this > kip. > >> > > >> > Thanks, > >> > Murali > >> > > >> > On Thu, Jul 4, 2024 at 9:58 PM Chia-Ping Tsai <chia7...@gmail.com> > >> wrote: > >> > > >> >> > > >> >> > Or do we also provide other binding jars for logback, log4j, simple > >> etc > >> >> ? > >> >> > >> >> > >> >> yep, that is a solution which kafka can have strong dependencies on > >> those, > >> >> but we need to reach the consensus about "which" providers should be > >> >> included > >> >> > >> >> Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 2024年7月5日 > 週五 > >> >> 上午3:50寫道： > >> >> > >> >> > Hi Chia, > >> >> > Thank you for dropping by on this. > >> >> > > >> >> > I have updated both the discussion thread and the Compatibility > >> section > >> >> > partly. But I would like to discuss a bit more about this and > update. > >> >> > > >> >> > 3. how to keep the compatibility of updating slf4j version in the > >> >> future? > >> >> > According to slf4j compatibility ( > >> >> > https://www.slf4j.org/manual.html#compatibility), users need to > >> update > >> >> > their binding version after we update the slf4j-api version. That > >> will > >> >> be a > >> >> > trouble as we have to file KIP every time in updating slf4j-api. > >> >> Including > >> >> > all binding jars in kafka is a solution, as we can take control > over > >> all > >> >> > binding jars. WDYT? > >> >> > Indeed, it is not ideal to file a kip always, and ship the upgraded > >> >> > slf4j-api jars. > >> >> > I like the approach of providing all binding jars within kafka, > >> however > >> >> I > >> >> > see we have only reload4j backend in our dependencies, or I could > be > >> >> wrong. > >> >> > So just providing a compatible reload4j with it should be ok ? > >> >> > Or do we also provide other binding jars for logback, log4j, simple > >> etc > >> >> ? > >> >> > > >> >> > Thanks, > >> >> > Murali > >> >> > > >> >> > On Thu, Jul 4, 2024 at 8:04 PM Chia-Ping Tsai <chia7...@gmail.com> > >> >> wrote: > >> >> > > >> >> > > hi Muralidhar > >> >> > > > >> >> > > thanks for writing the KIP. Please take a look at following > >> comments: > >> >> > > > >> >> > > 1. please update the Discussion thread. it has incorrect link > >> >> > > > >> >> > > 2. please complete the section "Compatibility, Deprecation, and > >> >> Migration > >> >> > > Plan". We had a good discussion in the PR ( > >> >> > > > https://github.com/apache/kafka/pull/16324#discussion_r1643359783 > >> ). > >> >> > > > >> >> > > 3. how to keep the compatibility of updating slf4j version in the > >> >> future? > >> >> > > According to slf4j compatibility ( > >> >> > > https://www.slf4j.org/manual.html#compatibility), users need to > >> >> update > >> >> > > their binding version after we update the slf4j-api version. That > >> will > >> >> > be a > >> >> > > trouble as we have to file KIP every time in updating slf4j-api. > >> >> > Including > >> >> > > all binding jars in kafka is a solution, as we can take control > >> over > >> >> all > >> >> > > binding jars. WDYT? > >> >> > > > >> >> > > Best, > >> >> > > Chia-Ping > >> >> > > > >> >> > > Muralidhar Basani <muralidhar.bas...@aiven.io.invalid> 於 > >> 2024年7月2日 週二 > >> >> > > 上午3:30寫道： > >> >> > > > >> >> > > > Hello, > >> >> > > > > >> >> > > > Regarding KIP-1064 [0], I would like to start a discussion on > >> >> upgrading > >> >> > > > slf4j to 2.x, which is currently at 1.7.36, and with an option > to > >> >> > > > provide slf4j provider in run class. > >> >> > > > > >> >> > > > This is also discussed in jira [1] and git pr [2], and thought > we > >> >> > should > >> >> > > > have a kip. > >> >> > > > > >> >> > > > Please note this kip is intended from kafka 4.0. > >> >> > > > > >> >> > > > [0] - > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1064%3A+Upgrade+slf4j+to+2.x > >> >> > > > [1] - https://issues.apache.org/jira/browse/KAFKA-16936 > >> >> > > > [2] - > >> >> > https://github.com/apache/kafka/pull/16324#discussion_r1644295632 > >> >> > > > > >> >> > > > Thanks, > >> >> > > > Murali > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > > >> > > >
