dev@hadoop.apache.org>"
mailto:mapreduce-dev@hadoop.apache.org>>,
"common-...@hadoop.apache.org<mailto:common-...@hadoop.apache.org>"
mailto:common-...@hadoop.apache.org>>
Subject: Re: [DISCUSS] Treating LimitedPrivate({"MapReduce"}) as Public APIs
for
Why don't we address these on a case-by-case basis, changing the
annotations on these key classes to Public? LimitedPrivate{"YARN
applications"} is the same thing as Public.
This way we don't need to add special exceptions to our compatibility
policy. Keeps it simple.
Best,
Andrew
On Tue, May 10
+1 for transitioning from LimitedPrivate to Public.
I view this as an extension of the need for UserGroupInformation and
related APIs to be Public. Regardless of the original intent behind
LimitedPrivate, these are de facto public now, because there is no viable
alternative for applications that
There seems to be some incorrect assumptions on why the application had an
issue. For rolling upgrade deployments, the application bundles the client-side
jars that it was compiled against and uses them in its classpath and expects to
be able to communicate with upgraded servers. Given that hado
> On May 10, 2016, at 8:37 AM, Hitesh Shah wrote:
>
> There have been various discussions on various JIRAs where upstream projects
> such as YARN apps ( Tez, Slider, etc ) are called out for using the above
> so-called Private APIs. A lot of YARN applications that have been built out
> have p
There have been various discussions on various JIRAs where upstream projects
such as YARN apps ( Tez, Slider, etc ) are called out for using the above
so-called Private APIs. A lot of YARN applications that have been built out
have picked up various bits and pieces of implementation from MapRedu
