tez-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Kelpe <ake...@concurrentinc.com>
Subject Re: api compatibility within a minor release
Date Thu, 20 Aug 2015 09:10:55 GMT
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 <hitesh@apache.org> 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 <akelpe@concurrentinc.com> 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
> > andre@concurrentinc.com
> > http://concurrentinc.com
>
>


-- 
André Kelpe
andre@concurrentinc.com
http://concurrentinc.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message