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
