ping, did this discussion conclude or did we decide what we are doing?
Tom
On Friday, May 13, 2016 3:19 PM, Michael Armbrust <mich...@databricks.com>
wrote:
+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
