Hi devs, I would like to start a discussion on FLIP-389: Annotate SingleThreadFetcherManager and FutureCompletingBlockingQueue as PublicEvolving.[ <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278465498> 1].
Though the SingleThreadFetcherManager is annotated as Internal, it actually acts as some-degree public API, which is widely used in many connector projects: flink-cdc-connector <https://github.com/ververica/flink-cdc-connectors/blob/release-2.3.0/flink-connector-mysql-cdc/src/main/java/com/ververica/cdc/connectors/mysql/source/reader/MySqlSourceReader.java#L93> , flink-connector-mongodb <https://github.com/apache/flink-connector-mongodb/blob/main/flink-connector-mongodb/src/main/java/org/apache/flink/connector/mongodb/source/reader/MongoSourceReader.java#L58> and soon. Moreover, even the constructor of SingleThreadMultiplexSourceReaderBase (which is PublicEvolving) includes the params of SingleThreadFetcherManager and FutureCompletingBlockingQueue. That means that the SingleThreadFetcherManager and FutureCompletingBlockingQueue have already been exposed to users for a long time and are widely used. Considering that all source implementations are using them de facto, why not annotate SingleThreadFetcherManager and FutureCompletingBlockingQueue as PublicEvolving so that developers will modify it more carefully to avoid any potential issues. As shown in FLINK-31324[2], FLINK-28853[3] used to change the default constructor of SingleThreadFetcherManager. However, it influenced a lot. Finally, the former constructor was added back and marked as Deprecated。 In conclusion, the goal of this FLIP is to annotate SingleThreadFetcherManager(includes its parent class) and FutureCompletingBlockingQueue as PublicEvolving. Looking forward to hearing from you. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278465498 [2] https://issues.apache.org/jira/browse/FLINK-31324 [3] https://issues.apache.org/jira/browse/FLINK-28853
