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 showed that the label code was broken ( YARN-5135 ) and the fixYARN-4991 not backported to branch-2
If the classes that had changed were tagged as @Private or @Evolving, I'd have just said, "oh well, never mind" Except, the two interfaces that broke: ContainerStatus and NodeReport —are marked @Public, @Stable Given that my code broke, I don't believe that the guarantees of a @Stable interface, "Can evolve while retaining compatibility for minor release boundaries; in other words, incompatible changes to APIs marked Stable are allowed only at major releases (i.e. at m.0)." are being kept. Now, in YARN-5130, we now have a patch to remark the interfaces as Unstable. However, while I can apply that patch myself, I want to raise a broader question: what does the Yarn team consider constitutes "stable"? And do that changes that took place in YARN-3886 and YARN-2882 meet those requirements? New methods are going in, some of which are now being tagged as @Evolving? I fail to see how something marked as @Stable can add @Evolving methods, and given that changes are breaking downstream code, I worry that not enough care is being taken over the maintenance of the guarantee which @Public, @Stable interfaces make to users -Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
