accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 19:34:10 GMT
On Thu, Dec 4, 2014 at 11:35 AM, Josh Elser <> wrote:

> John Vines wrote:
>> On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser<>  wrote:
>>  John Vines wrote:
>>>>>  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'm totally okay with this. But that means no requirements about APIs
>> from
>> 1.x to 2.0. I'd be comfortable with changing the verbiage to something
>> that
>> lessens to encourage effort to support deprecated APIs so long as they
>> don't influence 2.0 APIs.
> Sean, does this approach satisfy your concerns (both original and below)
> WRT verbage and what has been outlined for technical direction for RPC
> layer compatibility issues?

Sorry Josh, missed this earlier.

Are you saying we'd enforce no RPC removals or behavior changes prior to
2.x? If we were that would allow clients built against 1.6 (that only used
the public API) to continue running against clusters that upgrade to a
later 1.x without concern.

If we formally stated that in release notes by way of testing prior to
releases then it would address my concern, yes. (I agree with Mike though
that this vote thread is a mess and we'd need a clear follow on vote that
included what we're actually voting on.)


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