Hi Mason, I would be against making them part of the Public API. It would be against our current conventions and it would make future changes in this connector much more difficult. It's difficult to support Public APIs, even if they are `@PublicEvolving`.
Best, Piotrek pon., 29 sie 2022 o 19:17 Mason Chen <mas.chen6...@gmail.com> napisał(a): > Hi all, > > I know everyone is busy with preparing the 1.16 release. Just want to give > this thread a gentle ping, please give your +1 if there are no concerns! > > Best, > Mason > > On Thu, Aug 11, 2022 at 1:27 AM Mason Chen <mas.chen6...@gmail.com> wrote: > > > I understand that the 1.16 feature freeze is in place so I propose for > > these changes to go in the 1.17 release. > > > > Best, > > Mason > > > > On Thu, Aug 11, 2022 at 1:20 AM Mason Chen <mas.chen6...@gmail.com> > wrote: > > > >> Hi devs and community, > >> > >> I would like to discuss making the low level components of the KafkaSink > >> PublicEvolving. It looks like all of the classes are package private > apart > >> from the public facing API and classes were put in the same package to > make > >> this work. My desire to make at least the KafkaSinkWriter a public > class, > >> with no further changes to private/package-private methods. The > class(es) > >> would be annotated with PublicEvolving. > >> > >> I am in the process of implementing my own Sink that writes to Kafka and > >> I want to implement the SinkWriter by composing the functionality > contained > >> in the KafkaSinkWriter. There is significant work in this implementation > >> and I would like to use it and contribute back, bug fixes for example, > if I > >> find any in independent testing. > >> > >> Hopefully, that motivates the request. Please let me know your thoughts! > >> > >> Best, > >> Mason > >> > > >
