Thanks Sai Krishna for providing the historical context. +1 from my side.
Best Regards, Yuepeng Pan Krishna Sai <[email protected]> 于2026年9月16日周三 10:39写道： > Hi Yuepeng, > > Agreed on web.address. > > Your connector concern holds, and it is specific to > schema-registry.subject. apache/flink-connector-kafka still uses that > name on current main: KafkaConnectorOptionsUtil.autoCompleteSubject > builds "<format>.schema-registry.subject" and sets it to <topic>-value > or <topic>-key for the avro-confluent and debezium-avro-confluent > formats, called from both KafkaDynamicTableFactory and > UpsertKafkaDynamicTableFactory. So that fallback is actively written by > the connector today, and removing it from Flink would quietly stop the > automatic subject naming that the option's own description promises. > > schema-registry.url and schema-registry.schema are not referenced in any > of the 17 apache/flink-connector-* repositories, so the connector-first > ordering looks necessary only for .subject. > > One more thing that may help the scoping. The 2.0 release notes carry a > "List of removed configuration options" with 101 entries, and 22 of them > are still declared on master as deprecated or fallback keys, web.address > among them. That group looks like the least risky place to start, since > users were already told in 2.0 that those names were gone. > > Best regards, > Sai Krishna Sepuri > > On Tue, Sep 15, 2026 at 7:52 PM Yuepeng Pan <[email protected]> wrote: > > > > Thanks Sai Krishna for the confirmation. > > > > Overall, we can remove the web.address configuration option, while > keeping > > the others as its are. > > > > For schema-registry.*, > > This may affect the compatibility of external connectors. If we plan to > > remove these configuration items, we can first remove them from the > > corresponding connector repositories, > > and then remove the corresponding configurations from the Flink > repository. > > > > Please let me know your thoughts. > > > > Best regards, > > Yuepeng Pan > > > > > > > > Krishna Sai <[email protected]> 于2026年9月15日周二 15:43写道： > > > > > Hi Yuepeng, > > > > > > Thanks, line-level answers it. > > > > > > I scanned the full source tree of 13 release tags plus current master > > > instead of individual files, because these keys move between classes > > > (schema-registry.subject passed through three). On master there are 23 > > > withFallbackKeys sites: 9 pass a string literal, 14 reference another > > > option's key. That split is mechanical, so the two categories you want > > > separated can be told apart without judgement. The 9 literal sites > cover > > > 7 keys: > > > > > > schema-registry.url option until 1.13, fallback since 1.14 > > > schema-registry.subject option until 1.17 (last in the Kafka > > > connector), fallback only since 1.18 > > > schema-registry.schema never an option, fallback since 1.18 > > > web.address option until 1.20, marked @Deprecated for > > > years, fallback since 2.0 > > > s3.access.key never an option, fallback since 2.0 > > > s3.secret.key never an option, fallback since 2.0 > > > s3.path.style.access never an option, fallback since 2.3 > > > > > > So the s3 keys are recent, and s3.path.style.access only appeared in > > > 2.3, which settles those: leave them. web.address did carry a > > > deprecation marker while it was still an option. schema-registry.url is > > > the one that stands out, a silent fallback for about ten releases and > > > never marked deprecated. > > > > > > Best regards, > > > Sai Krishna Sepuri > > > >
