Re: [discuss] separate API annotation into two components: InterfaceAudience & InterfaceStability

[Reynold Xin <rx...@databricks.com>]

I think this is fairly important to do so I went ahead and created a PR for
the first mini step: https://github.com/apache/spark/pull/15374



On Wed, Aug 24, 2016 at 9:48 AM, Reynold Xin <rx...@databricks.com> wrote:

> Looks like I'm general people like it. Next step is for somebody to take
> the lead and implement it.
>
> Tom do you have cycles to do this?
>
>
> On Wednesday, August 24, 2016, Tom Graves <tg...@yahoo.com> wrote:
>
>> ping, did this discussion conclude or did we decide what we are doing?
>>
>> Tom
>>
>>
>> On Friday, May 13, 2016 3:19 PM, Michael Armbrust <mi...@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 <va...@cloudera.com>
>> wrote:
>>
>> On Fri, May 13, 2016 at 10:18 AM, Sean Busbey <bu...@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-unsubscribe@spark.apache.org
>> For additional commands, e-mail: dev-help@spark.apache.org
>>
>>
>>
>>
>>