Hi, (undusting this thread after a while)
I have opened https://issues.apache.org/jira/browse/TEZ-2981 to work around the issue. We believe that would be the best way forward. - André On Tue, Sep 15, 2015 at 11:04 PM, Hitesh Shah <[email protected]> wrote: > Hi Andre, > > I don’t believe I saw a JIRA created for this? Has this issue been > resolved? > > Also, it would be good if you can collate any particular private APIs that > you are using so that we can be aware of potential issues with such APIs. > > thanks > — Hitesh > > On Aug 20, 2015, at 2:10 AM, Andre Kelpe <[email protected]> wrote: > > > Thanks for the answer. We have a work-around for now. I am going to make > > that inventory and submit a patch that changes the annotations from > > @Private to @LimitedPrivate. > > > > From a semantic versioning point of view, I would still expect no > breaking > > changes in a bug fix release, but if the Tez community at large can work > > with that, we have to accept that, I guess. > > > > - André > > > > On Tue, Aug 18, 2015 at 8:34 PM, Hitesh Shah <[email protected]> wrote: > > > >> Hello Andre, > >> > >> For the most part, @Private is considered internal implementation and > >> subject to change at any point. In this case, even more so as it is an > >> *Impl class. > >> > >> What we can do is try the following: > >> - Look at all the various @Private classes being used by Cascading. > >> - See which ones should not be used at all and which ones can be > >> considered to be a @LimitedPrivate for Cascading. > >> - For LimitedPrivate apis, we would then try to be a bit more careful > >> with respect to changing/breaking these APIs. I would probably not say > that > >> they have will have the same guarantees as @Public/@Stable but we can > work > >> with the Cascading community to handle changes to these APIs in a > workable > >> manner on an ongoing basis. > >> > >> As for this API in question, for the short term fix, I guess a simple > >> approach might be to introduce a backward compatible API ( I believe one > >> which does not need the timeout param passed in )? Would you mind > filing a > >> jira and hopefully provide a patch too? > >> > >> thanks > >> — Hitesh > >> > >> On Aug 18, 2015, at 8:01 AM, Andre Kelpe <[email protected]> > wrote: > >> > >>> Hi, > >>> > >>> I have found a small API incompatibility in the Tez 0.6.2 release. The > >>> DAGClientTimelineImpl constructor got a new parameter for time-outs. > This > >>> was not present in 0.6.1 and from a semantic versioning point of view, > >> that > >>> is problematic. I know that the class is marked with the @Private > >>> annotation, but it would be great if such incompatible things aren't > >>> introduced in a bug-fix release. It would be easier for downsteam > >> projects, > >>> if you just added a second constructor. > >>> > >>> Is that an oversight or are classes with the @Private annotation > subject > >> to > >>> change and dowstream projects simply have to deal with it? > >>> > >>> Thanks! > >>> > >>> - André > >>> > >>> -- > >>> André Kelpe > >>> [email protected] > >>> http://concurrentinc.com > >> > >> > > > > > > -- > > André Kelpe > > [email protected] > > http://concurrentinc.com > > -- André Kelpe [email protected] http://concurrentinc.com
