Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.192.48 as permitted sender)
Message-ID: <5480C861.3030701@gmail.com>
Date: Thu, 04 Dec 2014 15:47:29 -0500
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [VOTE] API release policy for 1.7/2.0
References: 
 <CAL5zq9Y3Owj7dUd_ZZyhdGGZ7FQ+79ufgcLORJjjzUmMckBrsA@mail.gmail.com>
 <CADczPYRPmkJq-FOuwjp5NoYvF0Q+XdTrNSw0RmtR4uRkn=oNuw@mail.gmail.com>
 <CAGUtCHr1QsOEZ_dp4AA+LrsKMFWSYCCb6K13VT1WKBK+BnQkPA@mail.gmail.com>
 <CADczPYRn01Wgrj3upWTycwN8vFqWjNjduVEOV-0Y_wR=stKEHQ@mail.gmail.com>
 <CAGUtCHonoyQ_y8Oik45Sp9VL3_Hmr-AZr-iZqtSrCQYSn+AwrA@mail.gmail.com>
 <CADczPYQ6Stfu0Sb9AGDRQnXXNeKJHNL5otAUxQp4OZbqww4bJA@mail.gmail.com>
 <54808E84.9090403@gmail.com>
 <CAGUtCHoJRMKwFUFZmXgdgB3R8mQi3LKHq5XiZWONnXhgoZTUPQ@mail.gmail.com>
 <CADczPYS1Rfh4P0U_O2c1nCumcRcVeuBJJ8aY6iRn4tLBd9PEew@mail.gmail.com>
 <548095CB.2070803@gmail.com>
 <CADczPYQXeqn-O9w=KnPBzWZoKF_yaGXjdWLrL0o+cUz2PXRhLQ@mail.gmail.com>
 <54809B70.1070005@gmail.com>
 <CAGHyZ6+AhjkZnRurD2Rn3gKzWRNZE7bL1E_QSVrcbbejxwJDDA@mail.gmail.com>
In-Reply-To: 
 <CAGHyZ6+AhjkZnRurD2Rn3gKzWRNZE7bL1E_QSVrcbbejxwJDDA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Sean Busbey wrote:
> On Thu, Dec 4, 2014 at 11:35 AM, Josh Elser<josh.elser@gmail.com>  wrote:
>
>> John Vines wrote:
>>
>>> On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser<josh.elser@gmail.com>   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.