Deal all, It seems we need more discussion to reach the consensus on "rules" 1. minor/major release rule 2. 1 year rule
the recent adopted KIPs following only rule_1 are shown below: KIP-1041 https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=303794933 KIP-1013 https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=284789510 KIP-970 https://cwiki.apache.org/confluence/display/KAFKA/KIP-970%3A+Deprecate+and+remove+Connect%27s+redundant+task+configurations+endpoint Given that the topic needs more time (and love), maybe we can start vote on KIP-1067 (by accepting 4.0 temporarily) to make sure KIP-1067 gets deprecated in 3.9.0? Otherwise, the "start" of deprecation will get delayed again... Also, we can revisit all above KIPs after we reach the consensus on "deprecation rules" Best, Chia-Ping Justine Olshan <jols...@confluent.io.invalid> 於 2024年7月9日 週二 上午4:34寫道： > I was only aware of the minor/major release rule and not the 1 year rule. > Is this written down somewhere? > I only see this text about a "reasonable period" in > https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan > > I also see another example of deprecation in 3.7 and removal in 4.0. (For > reference the KIP suggests 4.0 would be in q3 2024 and 3.7 was released in > q1 2024) > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=284789510 > > Justine > > On Sun, Jul 7, 2024 at 8:26 PM Matthias J. Sax <mj...@apache.org> wrote: > > > Yes, we would need to wait for 5.0 to remove it (assuming 5.0 will go > > out more than a year later -- eg, we had 2.0 release after 1.1, and > > could not remove stuff deprecated in 0.11 either) > > > > > > >> Personally, the second rule is easy to follow, but the side effect is > > >> that the "deprecation cycle" is not fixed (for example, one year). > > > > Yes, it's _minimum_ of one year, plus an unknown amount of time until > > the next major release comes along. > > > > It has always been this way, and for Kafka Streams for example, we only > > consider to remove stuff in 4.0 that was deprecated in 3.6 or older > > releases (cf https://issues.apache.org/jira/browse/KAFKA-12822), > > including stuff deprecated in 2.7 and 2.8 which we could not remove in > 3.0. > > > > Let me follow up on KIP-1041 -- I don't think we can this this... > > > > > > >> Maybe it is a good time to have a discussion about the deprecation > > cycle. > > > > We can always discuss about it, but it has serves us well in the past. > > Personally, I don't see a reason why we would want to change it? > > > > > > > > > > -Matthias > > > > > > On 7/7/24 7:14 PM, Chia-Ping Tsai wrote: > > >> > > >> And even if we make an exception, > > >> we usually have a deprecation period of at least 1 year, so removing > the > > >> tool in 4.0 seems to be something we cannot do? > > > > > > > > > That is a good question, and I have had a similar question before. > > > > > > Deprecating it in 3.9 should be fine, so the problem is "can we remove > it > > > from 4.0"? > > > > > > 1) "we usually have a deprecation period of at least 1 year" this was > > what > > > I believed before. > > > 2) However, it seems another rule is "we don't introduce breaking > changes > > > in minor releases." > > > > > > If the above conditions have to be satisfied, I guess the version we > can > > > remove those deprecated stuff is 5.0.0 :) > > > > > > Also, there is another KIP trying to deprecate something in 3.8 and > then > > > remove it in 4.0. ( > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=303794933 > > ) > > > > > > Maybe it is a good time to have a discussion about the deprecation > cycle. > > > > > > Personally, the second rule is easy to follow, but the side effect is > > > that the "deprecation cycle" is not fixed (for example, one year). > > > > > > Best, > > > Chia-Ping > > > > > > Matthias J. Sax <mj...@apache.org> 於 2024年7月8日 週一 上午9:37寫道： > > > > > >> Hi, > > >> > > >> If I understand correctly, instead of maintaining the tool further > (via > > >> KIP-752) we want to deprecate the tool? > > >> > > >> This is fine, but it seem the KIP deadline for 3.9 passed, so we > cannot > > >> deprecate it in 3.9, but only in 4.0? And even if we make an > exception, > > >> we usually have a deprecation period of at least 1 year, so removing > the > > >> tool in 4.0 seems to be something we cannot do? > > >> > > >> > > >> -Matthias > > >> > > >> On 7/7/24 6:57 AM, Chia-Ping Tsai wrote: > > >>> +1 > > >>> > > >>> thanks Dongjin to start this discussion > > >>> > > >>> On 2024/07/07 12:58:45 Dongjin Lee wrote: > > >>>> Hello Kafka dev, > > >>>> > > >>>> I hope to start the discussion of KIP-1067: Remove > > >> ReplicaVerificationTool > > >>>> in 4.0 (deprecate in 3.9) > > >>>> < > > >> > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311627623 > > >>> . > > >>>> It replaces KIP-752: Support --bootstrap-server in > > >> ReplicaVerificationTool > > >>>> < > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-752%3A+Support+--bootstrap-server+in+ReplicaVerificationTool > > >>> > > >>>> . > > >>>> > > >>>> Thanks in advance for all discussions, feedbacks, etc. > > >>>> > > >>>> Best, > > >>>> Dongjin > > >>>> > > >>>> -- > > >>>> *Dongjin Lee* > > >>>> > > >>>> *A hitchhiker in the mathematical world.* > > >>>> > > >>>> > > >>>> > > >>>> *github: <http://goog_969573159/>github.com/dongjinleekr > > >>>> <https://github.com/dongjinleekr>keybase: > > >> https://keybase.io/dongjinleekr > > >>>> <https://keybase.io/dongjinleekr>linkedin: > > >> kr.linkedin.com/in/dongjinleekr > > >>>> <https://kr.linkedin.com/in/dongjinleekr>speakerdeck: > > >> speakerdeck.com/dongjin > > >>>> <https://speakerdeck.com/dongjin>* > > >>>> > > >> > > > > > >
