You definitely need to be careful with limitedPrivate as there are some interfaces tagged with that used by external components/Application masters. Some because there are no other alternatives. My feelings on limitedPrivate are to remove them and properly mark as either public or private, see https://issues.apache.org/jira/browse/HADOOP-10506. In the case of ResourceScheduler.reinitialize I would expect that to be mostly internal. There is the possibility someone wrote a specialized scheduler though. According to the definition of evolving it should be ok to change it: * Evolving, but can break compatibility at minor release (i.e. m.x)
But if you are just removing an unused parameter perhaps creating a new method and leave the existing (deprecating it) would be safer. Tom On 5/19/14, 8:20 PM, "Karthik Kambatla" <[email protected]> wrote: >Hi folks > >Just wanted to understand how kosher it is to change a >LimitedPrivate{"Yarn"}-Evolving interface in an incompatible way? Do we >try >not to change Evolving APIs as much as possible? How about removing an >unused parameter from a method? > >This is in the context of YARN-1474 changes to ResourceScheduler. I think >we should change the signature of ResourceScheduler#reinitialize. > >Also, I want to update LimitedPrivate{"Yarn"} to Private. > >Comments? > >Thanks >Karthik
