Hello Chris, Thanks for the input. I can see the issue with the deprecation field as a potential breaking change to the API but my thought was that it would be used to generate help and log entries if it was present, but I will leave that out for now.
I don't see that the builder will create a problem for older versions as it is used to produce the ConfigKeys that are currently produced by the ConfigKeys constructor(s). Since ConfigKeys are not final classes they can be extended and perhaps this is a way forward to verify and work out the deprecation before bringing it into the mainline Kafla code. In my opinion there is no need for a KIP since the builder does not impact any current implementations. Do you concur? Thanks again, Claude On Thu, May 29, 2025 at 12:36 PM Chris Egerton <fearthecel...@gmail.com> wrote: > Hi Claude, > > As a general improvement to our config API, this sounds fine (I'm perhaps a > little iffy on first-class support for deprecation instead of just adding a > note to the docstring, but that's low-level enough that it can and should > wait for a KIP before being discussed). > > However, if we're talking about doing this for connectors, one of the > challenges that arises is cross-version compatibility between workers and > connectors. Specifically, what happens when a connector built against this > new API is deployed onto a worker running run an older version? > > Cheers, > > Chris > > On Thu, May 29, 2025, 07:31 Claude Warren, Jr > <claude.war...@aiven.io.invalid> wrote: > > > I would like to implement a ConfigDef.ConfigKey builder. The goal is to > > have a fluent builder that will build the configKey and provide the same > > defaults that the current constructor set does. > > > > In addition, I would like to add the ability to make a ConfigKey as > > deprecated with some optional information like the version it was > > deprecated in, a description that can be used to specify the replacement > > and a flag to indicate that it will be removed soon. > > > > My goal is to make it easier to construct the ConfigKey and to make it > > easier to deprecate options as connectors and similar components evolve. > > > > Does anyone have any thoughts on this? Are there any objections? > > > > Claude > > >
