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 16:33:21 GMT
I'm not trying to say that we should accept a half-baked new API, just 
that, despite our best efforts, we'll likely mess up something 
(interface or implementation).

We want people to use and stick to the new API (better versioning should 
help us release quick fixes when we find aforementioned problems) to 
avoid a mapred/mapreduce-esque split -- also a large concern to me.

My last msg was more concerned with _trying_ to keep 100% compatibility 
with the 1.x API and addressing incompatible issues as they might arise 
in the development of the 2.0 API, instead of a declarative _must_.

Mike Drob wrote:
> I would very much like the new API to be something that we think has the
> right shape, ignoring implementation details. Otherwise we end up with
> something like a mapred/uce split and that still has people confused about
> which is the right one.
> On Thu, Dec 4, 2014 at 8:46 AM, Josh Elser<>  wrote:
>> Can we reach a compromise here that the general idea that had been
>> presented will be followed and, of such an impasse is found in supporting
>> the old api, we will have another discussion on what to do when we actually
>> have a concrete problem?
>> I feel like we can't get around this issue otherwise since it's a
>> hypothetical worry.
>> Planning on both APIs to be around saves us from having to get the new api
>> 100% right the first time around (because we all know the current api still
>> isn't there :)).
>> On Dec 4, 2014 9:24 AM, "John Vines"<>  wrote:
>>> On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey<>  wrote:
>>>> On Dec 4, 2014 6:55 AM, "Josh Elser"<>  wrote:
>>>>> (I was still confused so I just chatted with John on the subject of
>> his
>>>> -1)
>>>>> He was under the impression that it would not be feasible to leave
>> the
>>>> existing 1.X APIs in place with the creation of the 2.0 APIs; whereas,
>> I
>>>> had assumed that this wouldn't be an issue.
>>>>> He brought up the issue of how we plan to handle exceptions in the
>> new
>>>> API which, would very likely, include changes to the Thrift APIs as
>> well.
>>>> If this is the case, we'd now have to support the 1.X API (while it
>>> existed
>>>> as deprecated) as well as the new 2.0 API. This would likely affect how
>>> we
>>>> actually want 2.0 API to operate.
>>>>> This all kind of boils down to confusion over whether or not there is
>>> any
>>>> compatibility between 1.x and 2.0. If 2.0 is a clean break from 1.x,
>> this
>>>> thread is pointless. Otherwise, we risk not getting the APIs we really
>>>> want.
>>>>> Does this help clarify the concern?
>>>> One way to address that kind of concern would be to only support the
>> 1.x
>>>> APIs via an optional different end point.
>>>> We obviously don't have enough information at this point to evaluate
>> how
>>>> much such a separation would take to implement nor how maintainable it
>>>> would be.
>>>> But there at least seems to be a way to work through that issue if it
>>> comes
>>>> up.
>>> I hope so. But until we have a new API fully implemented that we're
>> content
>>> with, I don't think we should have any guarantees made about
>> compatibility
>>> of the 1.x API, just in case we end up hitting an insurmountable issue.

View raw message