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 >
