+1 to the general structure of Reynold's proposal. I've found what we do currently a little confusing. In particular, it doesn't make much sense that @DeveloperApi things are always labeled as possibly changing. For example the Data Source API should arguably be one of the most stable interfaces since its very difficult for users to recompile libraries that might break when there are changes.
For a similar reason, I don't really see the point of LimitedPrivate. The goal here should be communication of promises of stability or future stability. Regarding Developer vs. Public. I don't care too much about the naming, but it does seem useful to differentiate APIs that we expect end users to consume from those that are used to augment Spark. "Library" and "Application" also seem reasonable. On Fri, May 13, 2016 at 11:15 AM, Marcelo Vanzin <van...@cloudera.com> wrote: > On Fri, May 13, 2016 at 10:18 AM, Sean Busbey <bus...@cloudera.com> wrote: > > I think LimitedPrivate gets a bad rap due to the way it is misused in > > Hadoop. The use case here -- "we offer this to developers of > > intermediate layers; those willing to update their software as we > > update ours" > > I think "LimitedPrivate" is a rather confusing name for that. I think > Reynold's first e-mail better matches that use case: this would be > "InterfaceAudience(Developer)" and "InterfaceStability(Experimental)". > > But I don't really like "Developer" as a name here, because it's > ambiguous. Developer of what? Theoretically everybody writing Spark or > on top of its APIs is a developer. In that sense, I prefer using > something like "Library" and "Application" instead of "Developer" and > "Public". > > Personally, in fact, I don't see a lot of gain in differentiating > between the target users of an interface... knowing whether it's a > stable interface or not is a lot more useful. If you're equating a > "developer API" with "it's not really stable", then you don't really > need two annotations for that - just say it's not stable. > > -- > Marcelo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org > For additional commands, e-mail: dev-h...@spark.apache.org > >
