Hi Becket, May I ask what is the motivation for the change?
I'm really skeptical about making any of those classes `Public` or `PublicEvolving`. As far as I am concerned there is no agreement in the community if StreamOperator is part of the `Public(Evolving)` API. At least I think it should not. I understand `AbstractStreamOperator` was marked with `PublicEvolving`, but I am really not convinced it was the right decision.
The listed classes are not the only classes exposed to `AbstractStreamOperator` that are `Internal` that break the consistency and I am sure there is no question those should remain `Internal` such as e.g. StreamTask, StreamConfig, StreamingRuntimeContext and many more.
As it stands I am strongly against giving any additional guarantees on API stability to the classes there unless there is a good motivation for a given feature and we're sure this is the best way to go forward.
Thus I'm inclined to go with -1 on any proposal on changing annotations for the sake of matching the one on `AbstractStreamOperator`. I might be convinced to support requests to give better guarantees for well motivated features that are now internal though.
Best, Dawid On 12/01/2023 10:20, Becket Qin wrote:
Hi flink devs, I'd like to start a discussion thread for FLIP-286[1]. As a recap, currently while AbstractStreamOperator is a class marked as @PublicEvolving, some classes exposed via its methods / fields are marked as @Internal. This FLIP wants to fix this inconsistency of stability / scope annotation. Comments are welcome! Thanks, Jiangjie (Becket) Qin [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=240880841
OpenPGP_0x31D2DD10BFC15A2D.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
