Thanks Justine to confirm the rules

I have updated the rules to Time Based Release Plan (
https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan),
see following:

We break compatibility (i.e. remove deprecated public methods after a
> reasonable period, and typically wait 1 year after deprecation).



I think there could be an argument for deprecating this tool sooner than a
> year. (It is likely not used in production setups) But I am also ok with
> waiting a year if we think it is needed.


I have no strong reason to remove that tool in 4.0, so let's follow the
1-year rule to remove it in 5.0

Dongjin WDYT?


Justine Olshan <jols...@confluent.io.invalid> 於 2024年7月9日 週二 下午11:24寫道:

> Hey all,
>
> I agree with Chia-Ping that the deprecation should definitely occur in 3.9.
>
> My understanding (after discussing offline with some folks) is that we
> typically wait 1 year after deprecation, but there are some exceptions to
> that rule. For KIP-1013, we traded off not waiting the whole period in
> order to get broker and tools deprecation before clients. This was done
> after some careful consideration and it ended up being almost a year anyway
> with the 3.8 and 3.9 releases :)
>
> I think there could be an argument for deprecating this tool sooner than a
> year. (It is likely not used in production setups) But I am also ok with
> waiting a year if we think it is needed.
>
> Justine
>
> On Tue, Jul 9, 2024 at 5:37 AM Chia-Ping Tsai <chia7...@gmail.com> wrote:
>
> > 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=303794933KIP-1013
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=284789510
> > KIP-970
> > <
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=284789510KIP-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>*
> > > > >>>>
> > > > >>
> > > > >
> > > >
> > >
> >
>

Reply via email to