Hi Divij, The KIP didn't state this, but the usual practice is to have a deprecation period before we make incompatible changes. Why did we reject this option? We should mention that explicitly in the KIP.
Ismael On Tue, Nov 19, 2024, 2:55 AM Divij Vaidya <divijvaidy...@gmail.com> wrote: > KT1 - That is right. We will throw a ConfigException. That is why this > change is considered backward incompatible. To be honest, given the nature > of suggested changes, I don't see any valid use case on why a user may have > a value which will be invalid after the new constraints. > > > -- > Divij Vaidya > > > > On Tue, Nov 19, 2024 at 2:21 AM Kirk True <k...@kirktrue.pro> wrote: > > > Hi Divij, > > > > Thanks for the KIP! > > > > My only question: > > > > KT1. In the case where we change the constraints so that a user's > > previously valid configuration is now invalid, do we do anything other > than > > throw a ConfigException? > > > > Thanks, > > Kirk > > > > On Mon, Nov 18, 2024, at 2:13 AM, Divij Vaidya wrote: > > > Hey folks > > > > > > With 4.0, we have an opportunity to reset the default values and add > > > constraints in the configurations based on our learnings since 3.0. > > > > > > Here's a KIP which modifies defaults for some properties and modifies > the > > > constraints for a few others. > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1030%3A+Change+constraints+and+default+values+for+various+configurations > > > > > > > > > Looking forward for your feedback. > > > > > > (Previous discussion thread on this topic - > > > https://lists.apache.org/thread/3dx9mdmsqf8pko9xdmhks80k96g650zp ) > > > > > >
