accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 18:11:57 GMT
Yes, you have identified the issues I perceive.

A proxy is one acceptable solution, yes. But given the statements people
have made about wanting to keep things around like the 1.x batchwriter API,
I question how acceptable running proxies will be / the cost of
implementing and maintaining a full proxy for a subset of features we
require for compatibility.

I wish I had a better solution to punting until we have 2.0's client API
finalized, but I see little recourse for any API guarantees we make for
2.0.0 until we have that API in hand.

On Thu, Dec 4, 2014 at 12:29 PM, Sean Busbey <busbey@cloudera.com> wrote:

> On Thu, Dec 4, 2014 at 11:11 AM, Josh Elser <josh.elser@gmail.com> wrote:
>
> > John Vines wrote:
> >
> >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner<keith@deenlo.com>  wrote:
> >>
> >>  On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser<josh.elser@gmail.com>
> >>> wrote:
> >>>
> >>>  John Vines wrote:
> >>>>
> >>>>  Though I feel the biggest reasoning is our switch to semantic
> >>>>>
> >>>>>> versioning. And from semver.org,
> >>>>>>
> >>>>>>>   >
> >>>>>>>
> >>>>>>>>   >
> >>>>>>>>   >       1. MAJOR version when you make incompatible
API changes
> >>>>>>>>   >
> >>>>>>>>   >
> >>>>>>>>   >
> >>>>>>>>
> >>>>>>>   Right and dropping deprecated APIs is an incompatible
change. Do
> >>>>>>> you
> >>>>>>>
> >>>>>> think
> >>>>>>
> >>>>>>>   the following two rules are reasonable?
> >>>>>>>
> >>>>>>>     * When API is deprecated, must offer replacement if
feasible.
> >>>>>>>     * Can only drop deprecated method when MAJOR version
is
> >>>>>>>
> >>>>>> incremented
> >>>
> >>>> (there
> >>>>>
> >>>>>    are other proposed constraints on dropping deprecated methods)
> >>>>>>>
> >>>>>>>   If we follow the above, then we can not deprecate current
API
> >>>>>>> before
> >>>>>>>   introducing new API (because the replacement would not
exist
> >>>>>>>   concurrently).  Also we can not drop the current API in
2.0.0 if
> >>>>>>> its
> >>>>>>>
> >>>>>> not
> >>>>>>
> >>>>>>>   deprecated.
> >>>>>>>
> >>>>>> It is totally a reasonable statement for after 2.0.0. But for
2.0.0
> I
> >>>>> am
> >>>>> not okay making this guarantee because I would rather sacrifice
> >>>>> backward
> >>>>> compatibility for an API that isn't plagued by shortcomings of the
> old
> >>>>>
> >>>> API
> >>>
> >>>> Again, this is the fear/concern of impacting the new API due to
> >>>>
> >>> supporting
> >>>
> >>>> of the old which *may or may not even happen*.
> >>>>
> >>>>  Good point, we could adopt these rules now and never create a new
> >>> API.  I
> >>> think we would be better off adopting this now regardless of wether not
> >>> we
> >>> introduce a new API in the future.
> >>>
> >>> Also, if we do eventually create an API.  How is it user unfriendly to
> >>> have
> >>> the old API around in deprecated form?  The deprecation markings
> clearly
> >>> communicate that someone writing new code should not use the old API.
> >>> However it still allows existing code that users invested time into
> >>> writing
> >>> to run w/o issue against 2.0.0.
> >>>
> >>>
> >> I feel like I'm repeating myself. My concern is that the implementation
> >> details of maintaining the 1.x API in deprecated form will have a
> negative
> >> impact on the 2.0 API due to implementation details.
> >>
> >
> > Sorry, Keith, you misinterpreted what I meant -- let me try to restate. I
> > am assuming that a new API will happen.
> >
> > What is only a possibility is that the old API implementation would
> > negatively affect the new API. John's concern is a hypothetical one that
> > isn't based on any *actual* implementation details. He's assuming that we
> > will hit some sort of roadblock which we would be unable to resolve in a
> > desirable way (a way that would not negatively impact 2.0 API).
> >
> > What I'm saying is that we should address those issues if and when we get
> > there. When we have context to a concrete problem, we can make a decision
> > there about how to proceed. Meanwhile, we act under best-intentions to
> keep
> > the 1.0 APIs around.
> >
> > Do you get what I'm suggesting, John?
> >
> >
> I think that if we make a promise now, in this vote, that we are going to
> keep (some subset of) 1.x APIs alive during the 2.x release frame, we will
> be hard pressed to pass a vote to go back on that promise in 6-9 months
> when the changes for 2.x get firmer. I think this is the crux of John's
> opposition.
>
> If I understand the rest of John's concern correctly, the risk of keeping
> around the old 1.x API having an impact on the form of the new 2.x API is
> largely tied to involvement in the RPC layer.
>
> In the event that the 2.x API wants a change to the RPC that isn't
> compatible with the 1.x API, one mitigation strategy (albeit extreme) is to
> rely on a proxy to do the translation between old clients and a cluster
> running the new services. Such a proxy may need to be non-trivial depending
> on how well we're trying to support the 1.x API. For example, if we want
> all of the batch writer stuff to work we may need to have a proxy service
> running alongside each tserver.  We could easily set acceptance criteria
> for 1.x compatibility that bounds how much of e.g. a performance hit the
> proxy introduces for folks upgrading from 1.x. The important bit is that
> whatever form the proxy takes, it would be optional and only needed for
> folks who want compatibility with the 1.x API.
>
> John, does it sound like I understand your concerns correctly?
>
> Does the above outline of a proxy based mitigation for having 1.x and 2.x
> APIs coexist help at all?
>
> --
> Sean
>

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