Return-Path: X-Original-To: apmail-flink-dev-archive@www.apache.org Delivered-To: apmail-flink-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0C7E118A9D for ; Tue, 10 Nov 2015 20:07:00 +0000 (UTC) Received: (qmail 94774 invoked by uid 500); 10 Nov 2015 20:06:59 -0000 Delivered-To: apmail-flink-dev-archive@flink.apache.org Received: (qmail 94703 invoked by uid 500); 10 Nov 2015 20:06:59 -0000 Mailing-List: contact dev-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flink.apache.org Delivered-To: mailing list dev@flink.apache.org Received: (qmail 94690 invoked by uid 99); 10 Nov 2015 20:06:59 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Nov 2015 20:06:59 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 2C0221A0AD3 for ; Tue, 10 Nov 2015 20:06:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.007 X-Spam-Level: *** X-Spam-Status: No, score=3.007 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.008, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 6Mx5zOToJWkA for ; Tue, 10 Nov 2015 20:06:57 +0000 (UTC) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id CEA67215DF for ; Tue, 10 Nov 2015 20:06:56 +0000 (UTC) Received: by qgec40 with SMTP id c40so7549368qge.2 for ; Tue, 10 Nov 2015 12:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Jo6aeFPenM/bTjtvugH9wo24tYVWEbH1zh0jBvmLZQE=; b=jMTZ06Cl27KIsYP2zzEciUDFAkpXD4scoqNPELCqEkhsDZDo+hdcDPyJMpLL2X+I5S 6OaibCjwZpKaFm5w5oeWhMm4bpWtmEPCfpnMqWc+OvB++Zl3CzCACUWDAEcw+Nbc6/S0 GXH8ysNkeEbxWG4SJA/id7ZEtI9E9gMp7wmpuXNHbiXZxNmEGCWnDFuGoPzt3JSxMHVr wKDIAxH1nbIyUqJ8WCREsQQ9hZoVL5+Cvdev7RRp1HU7dJJVutW98hkISGoC1U6cKZ9V MFOU8mxr8BftWQ4e2Dcd9WeMPylWHXUT8fMy+DXizaicl4akukkQ6utjwkzcOLV0aMOf Tl+g== MIME-Version: 1.0 X-Received: by 10.140.18.172 with SMTP id 41mr6572387qgf.99.1447186015845; Tue, 10 Nov 2015 12:06:55 -0800 (PST) Sender: ewenstephan@gmail.com Received: by 10.55.147.1 with HTTP; Tue, 10 Nov 2015 12:06:55 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Nov 2015 21:06:55 +0100 X-Google-Sender-Auth: jXjlSTqAl4HbzG5x16g2nEITCHk Message-ID: Subject: Re: Tagging Flink classes with InterfaceAudience and InterfaceStability From: Stephan Ewen To: "dev@flink.apache.org" Content-Type: multipart/alternative; boundary=001a1135636c660260052435403d --001a1135636c660260052435403d Content-Type: text/plain; charset=UTF-8 I think no component should be forced to be stable. It should be an individual decision for each component, and in some cases even for individual classes. @Vasia If you think Gelly should not be declared interface-frozen, then this is a good point to raise and this should definitely be reflected. There is no point in declaring certain APIs as frozen when we are not yet confident they have converged. On Tue, Nov 10, 2015 at 8:39 PM, Vasiliki Kalavri wrote: > Hi Robert, > > thanks for bringing this up! > > I generally like the idea, but I wouldn't rush to annotate the Gelly > classes yet. Gelly hasn't had that many users and I'm quite sure we'll find > things to improve as it gets more exposure. > TBH, I think it's quite unfair to force Gelly (also e.g. ML, Table) to a > "1.0" status (from an API stability point of view) since they're really > young compared to the other Flink APIs. > > Cheers, > Vasia. > On Nov 10, 2015 8:04 PM, "Robert Metzger" wrote: > > > Hi everyone, > > > > I would like to bring this discussion back to your attention as we seem > to > > approach the 1.0 release of Flink. > > > > My suggestion back in January was to annotate all classes, but I think > > it'll be more feasible to just annotate public classes. > > So how about adding an annotation @PublicInterface > > > > For @PublicInterface, I would annotate classes such as: DataSet, > > DataStream, ExecutionEnvironment, InputFormat, MapFunction, FileSystems > but > > also Gelly for example. > > > > I would not annotate as public components such as ML, Storm > compatibility, > > internals from runtime, yarn, optimizer. > > > > > > From a tooling perspective, I've looked into different maven plugins and > > java libraries and I found https://github.com/siom79/japicmp to be the > > closest to our needs. I actually opened a pull request to the project to > > allow inclusion/exclusion of classes based on annotations. Lets hope it > > gets merged. > > > > Does everybody agree with adding just the @PublicInterface annotation? > > > > Note that I'll add the annotation on a class-level, making the entire > class > > either public or private (from a stability point of view). If we need a > > more fine-grained annotation, we have to add a second @PrivateInterface > > annotation which we'll only apply to certain methods. > > > > The next step is that I'm going to open a pull request with all classes > > annotated that I consider public. > > > > > > On Fri, Jan 30, 2015 at 7:10 PM, Henry Saputra > > wrote: > > > > > I like the idea. But would love to have different name for the > > > "LimitedPrivate" to make it easier to distinguish. > > > How about "Module" or "Package" ? > > > > > > - Henry > > > > > > On Wed, Jan 28, 2015 at 1:29 AM, Robert Metzger > > > wrote: > > > > I think in Hadoop they use LimitedPrivate for the different > components > > of > > > > the project. > > > > For example LimitedPrivate("yarn"). > > > > Here is a very good documentation on the topic: > > > > > > > > > > https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/InterfaceClassification.html > > > > > > > > On Tue, Jan 27, 2015 at 3:58 PM, Alexander Alexandrov < > > > > alexander.s.alexandrov@gmail.com> wrote: > > > > > > > >> I don't get the difference between Private and LimitedPrivate, but > > > >> otherwise seems like quite a nice idea. > > > >> > > > >> It will be also good if we can agree upon what these tags actually > > mean > > > and > > > >> add this meaning to the documentation. > > > >> > > > >> 2015-01-27 15:46 GMT+01:00 Robert Metzger : > > > >> > > > >> > Hi, > > > >> > > > > >> > Hadoop has annotations for tagging the stability and audience of > > > classes > > > >> > and methods. > > > >> > > > > >> > Through that, you can have @InterfaceAudience.Public, Private, > > > >> > LimitedPrivate > > > >> > and also @InterfaceStability.Evolving, Unstable, and Stable. > > > >> > > > > >> > I guess there are tools which allow to automatically check if > > > interfaces, > > > >> > which are marked as Stable have been changed between releases (or > by > > > pull > > > >> > requests). > > > >> > > > > >> > I think such annotations are crucial if we want to guarantee > > interface > > > >> > stability between releases. > > > >> > > > > >> > What do you think? Should we add those annotations? Which one > would > > > you > > > >> > like to add? > > > >> > > > > >> > > > > >> > Robert > > > >> > > > > >> > > > > > > --001a1135636c660260052435403d--