Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

Yeah, I should have been precise. I was referring to the Hadoop annotations regarding visibility/stability, not java's visibility. On Fri, Oct 28, 2016 at 10:38 AM, Ravi Prakash wrote: > Thanks for the clarification. "regardless of the method > visibility/stability"

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

Thanks for the clarification. "regardless of the method visibility/stability" confused me for a bit. On Fri, Oct 28, 2016 at 10:31 AM, Sangjin Lee wrote: > No, private methods are free to change as far as the class contract is > concerned. > > On Fri, Oct 28, 2016 at 10:30 AM,

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

No, private methods are free to change as far as the class contract is concerned. On Fri, Oct 28, 2016 at 10:30 AM, Ravi Prakash wrote: > Would this mean that if there is a private method in MyPublicStableClass, > changing which wouldn't break anything, could we still not

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

Would this mean that if there is a private method in MyPublicStableClass, changing which wouldn't break anything, could we still not change it? On Thu, Oct 27, 2016 at 2:55 PM, Sangjin Lee wrote: > Resurrecting an old thread as part of the YARN bug bash (YARN-5130). > > At

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

Resurrecting an old thread as part of the YARN bug bash (YARN-5130). At minimum, I believe we agree to the following (do let me know if that is not the case): (1) If the class is declared Public/Stable, no changes to the class that breaks the Stable contract should be made between non-major

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

On Tue, May 31, 2016 at 10:10 AM, Chris Nauroth wrote: > I recommend that we update the compatibility guide with some text that > explicitly addresses subclassing/interface inheritance stability for > classes/interfaces annotated Stable. This is for our own benefit

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

On Mon, May 30, 2016 at 9:44 PM, Karthik Kambatla wrote: > Inline. > > On Sat, May 28, 2016 at 11:34 AM, Sangjin Lee wrote: > >> I think there is more to it. The InterfaceStability javadoc states: >> Incompatible changes must not be made to classes

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

I recommend that we update the compatibility guide with some text that explicitly addresses subclassing/interface inheritance stability for classes/interfaces annotated Stable. This is for our own benefit too. (I often refer back to that doc when I'm coding a patch that might have a chance of

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

On 31 May 2016, at 05:44, Karthik Kambatla > wrote: Inline. On Sat, May 28, 2016 at 11:34 AM, Sangjin Lee > wrote: I think there is more to it. The InterfaceStability javadoc states: Incompatible

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

Inline. On Sat, May 28, 2016 at 11:34 AM, Sangjin Lee wrote: > I think there is more to it. The InterfaceStability javadoc states: > Incompatible changes must not be made to classes marked as stable. > > And in practice, I don't think the class annotation can be considered

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

I think there is more to it. The InterfaceStability javadoc states: Incompatible changes must not be made to classes marked as stable. And in practice, I don't think the class annotation can be considered a simple sum of method annotations. There is a notion of class compatibility distinct

Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs

Inline. On Sat, May 28, 2016 at 3:51 AM, Steve Loughran wrote: > > In SLIDER-1130, I discovered that some changes to some YARN classes had > broken my test code —new abstract methods had been defined, which broke the > subclasses I have to mock a YARN cluster. These are

[DISCUSS] what exactly are the stability guarantees of the YARN APIs

In SLIDER-1130, I discovered that some changes to some YARN classes had broken my test code —new abstract methods had been defined, which broke the subclasses I have to mock a YARN cluster. These are invaluable classes, as, once eventually the hadoop regressions had been worked around, they