accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 20:47:29 GMT
Sean Busbey wrote:
> 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.)

No worries, I sent it after your last message anyways. And yes, I meant 
it as a mix of your previous message (the one where you talked about 
introducing a proxy for compat) and the above. Thanks.

View raw message