I think in general annotating library methods/classes is a good idea. The question is just which APIs are going to be marked stable.
In the past we've seen that we might have marked some of Flink's APIs stable too early. As a consequence we have to carry them along for quite some time (at the very least until Flink 2.0). If we now come to the conclusion that the library APIs are not yet stable enough to mark them Public, then we will probably mark a lot of the API PublicEvolving which adds only little value for the user. Cheers, Till On Wed, Nov 23, 2016 at 2:25 PM, Aljoscha Krettek <aljos...@apache.org> wrote: > I would be for also annotating library methods/classes. Maybe Robert has a > stronger opinion on this because he introduced these annotations. > > On Tue, 22 Nov 2016 at 18:56 Greg Hogan <c...@greghogan.com> wrote: > > > Hi all, > > > > Should stable APIs in Flink's CEP, ML, and Gelly libraries be annotated > > @Public or restricted to use of @PublicEvolving? > > > > We would ensure that library APIs do not add restrictions to the core > APIs. > > Libraries could use @PublicEvolving or @Internal core APIs within @Public > > or @PublicEvolving components as long as the functionality could be > adapted > > or rewritten as necessary. An example: CombineHint is @Internal. Gelly > > could use CombineHint in a @Public method but could not accept > CombineHint > > as a parameter to a @Public method. > > > > Greg > > >
