hi David thanks for quickly response!!
According to KIP-906, the BC rules are 1) The old package name must be deprecated in the target release (e.g. 3.5) and redirection removed in the next major release (e.g. 4.0). 2) Existing users will get a deprecation warning when using the old package name, while old SPIs and classes will be marked as deprecated. I will file a jira to make sure we don't violate that rules Best, Chia-Ping David Jacot <dja...@confluent.io.invalid> 於 2024年4月10日 週三 下午8:57寫道： > Hey, > > I think that we discussed this in this KIP: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-906%3A+Tools+migration+guidelines > . > I don't remember all the details though. > > Best, > David > > On Wed, Apr 10, 2024 at 2:54 PM Chia-Ping Tsai <chia7...@gmail.com> wrote: > > > Dear Kafka, > > > > Migrating command tools from core module to tools module is not news. > > However, I want to make sure I don't misunderstand the BC rules. > > > > The question is "Should we keep origin class?" > > > > FeatureCommand ( > > > > > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/admin/FeatureCommand.scala > > ) > > is a good example. We keep the origin class file due to backward > > compatibility. However, we don't do that to other tools. > > > > It seems to me that we should align the BC rules for all tools. And here > is > > my two cents: the expected way of using command tool is by script file, > so > > we DON'T need to keep origin class file. > > > > WDYT? > > > > Best, > > Chia-Ping > > >
