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
