Can I start a vote on this? ~ Rajani
On Mon, Jul 21, 2025 at 10:23 AM Rajani Karuturi <rajanikarut...@gmail.com> wrote: > Hi Matthias and Chia-Ping > I updated the KIP and removed references of deprecated methods. It only > talks about BrokerNotFoundException now. > Can you please review one more time? > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1195%3A+deprecate+and+remove+org.apache.kafka.streams.errors.BrokerNotFoundException > > > Thanks, > ~ Rajani > > > On Sun, Jul 20, 2025 at 8:36 PM Chia-Ping Tsai <chia7...@apache.org> > wrote: > >> hi Rajani >> >> I think the section "Deprecated Methods for Removal:" could be removed >> from this KIP, since they are already deprecated, as Matthias mentioned. >> >> Best, >> Chia-Ping >> >> On 2025/07/18 05:52:53 Rajani Karuturi wrote: >> > Updated KIP to reflect deprecation in 4.2 and removal in the next major >> > release. >> > >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=373886192 >> > >> > >> > Thanks, >> > ~ Rajani >> > >> > >> > On Fri, Jul 18, 2025 at 9:23 AM Rajani Karuturi < >> rajanikarut...@gmail.com> >> > wrote: >> > >> > > ok, agree on the deprecation cycle. I will mark >> BrokerNotFoundException as >> > > deprecated and raise a PR which can be merged to master for the next >> 4.x >> > > release. >> > > How do we handle other deprecated methods from the exception handlers? >> > > Should I raise a PR and keep it unmerged until the 5.x release cycle >> > > starts? >> > > >> > > Thanks, >> > > ~ Rajani >> > > >> > > >> > > On Thu, Jul 17, 2025 at 11:01 PM Chia-Ping Tsai <chia7...@gmail.com> >> > > wrote: >> > > >> > >> > there is also no damage if we only deprecate it for now, and wait >> for >> > >> 5.0 release to remove it. >> > >> >> > >> agreed. Keeping it in 4.x won't burn out the kafka server, so let's >> follow >> > >> the deprecation cycle. >> > >> >> > >> Matthias J. Sax <mj...@apache.org> 於 2025年7月18日 週五 上午12:17寫道： >> > >> >> > >> > Thanks for the KIP Rajani. >> > >> > >> > >> > `BrokerNotFoundException` is unused for a long time, and I am >> happy to >> > >> > get rid of it. >> > >> > >> > >> > However, I am not sure, if we can remove it directly -- at least, >> that >> > >> > would not be regular protocol. We usually first deprecate >> > >> > interfaces/classes/methods we want to remove, and remove them only >> in >> > >> > the next major release (if they are deprecated for at least 3 >> releases / >> > >> > 1 year). >> > >> > >> > >> > Given that `BrokerNotFoundException` is unused for a very long >> time, we >> > >> > could make an exception and remove directly, but on the other hand, >> > >> > there is also no damage if we only deprecate it for now, and wait >> for >> > >> > 5.0 release to remove it. >> > >> > >> > >> > Curious to hear from others what they thing about this. >> > >> > >> > >> > >> > >> > For the other methods from the exception handlers you list on the >> KIP, >> > >> > all these are already deprecated. However, we could not remove >> them with >> > >> > 4.0 release, because they did not meet the 3-release/1-year grace >> period >> > >> > for removal. Thus, we can only remove them with 5.0 release (we >> don't >> > >> > need a KIP for this, as the removal is implicitly approved with >> the KIPs >> > >> > which deprecated these methods). >> > >> > >> > >> > >> > >> > -Matthias >> > >> > >> > >> > On 7/16/25 2:36 AM, Rajani Karuturi wrote: >> > >> > > Hi All, >> > >> > > >> > >> > > I would like to start a discussion for KIP-1195( >> > >> > > >> > >> > >> > >> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=373886192 >> > >> > ) >> > >> > > >> > >> > > Over time, certain exceptions and methods within the Kafka >> Streams >> > >> > > exception handling interfaces have been deprecated in favor of >> newer, >> > >> > more >> > >> > > comprehensive alternatives. Retaining these deprecated elements >> can >> > >> lead >> > >> > to >> > >> > > confusion, and complicates future development and maintenance. >> This >> > >> KIP >> > >> > > proposes the removal of these specific deprecated exceptions and >> > >> methods >> > >> > to >> > >> > > streamline the API and improve code clarity. >> > >> > > >> > >> > > Thanks, >> > >> > > ~ Rajani >> > >> > > >> > >> > >> > >> > >> > >> >> > > >> > >> >
