accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 17:34:39 GMT
Sean Busbey 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?
>

We probably wouldn't need a separate RPC server to get what you 
suggested, Sean. We could just support extra methods on the existing 
servers and then get rid of the old ones when we officially drop 1.x API 
support.

Mime
View raw message