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: [DISCUSS] How to bring more pluggable interfaces into public API
Date Fri, 26 Aug 2016 20:51:16 GMT


Christopher wrote:
> On Fri, Aug 26, 2016 at 1:25 PM Sean Busbey<busbey@cloudera.com>  wrote:
>
>> On Fri, Aug 26, 2016 at 11:58 AM, Christopher<ctubbsii@apache.org>  wrote:
>>> +1 for creating supported interfaces in our public API for these.
>>> Right now, I think all of these areas are suffering from bit
>> rot/technical
>>> debt, and need to be cleaned up before (or in the process of) exposing
>> them
>>> as public API.
>>>
>>
>> Can we make this clean up a goal for a>=Accumulo 3.0 world? Or since
>> we'd be adding to the public API maybe>=Accumulo 2.y for some y>= 1?
>>
>>
> Do you mean add the suggested items to the public API as is, for 2.0, and
> clean them up later? Or add them later?
>
> I could go either way... but I guess my point was that they currently
> aren't suitable for public API, due to how coupled they are to internal
> classes/code (like the KeyExtent issue that prompted this discussion). So,
> I'd want some minimal cleanup, if we can, just to try to make them suitable
> for public API in this sense, before adding them. Then, incremental
> improvements can occur later.
>
>
>
>> We're long for a 2.0 release, and the sooner we get it out the door
>> (if only just for the java 8+ only change) the better chances we're
>> giving to downstream folks to move to it in an orderly manner. I'd
>> prefer we not delay that further for API additions. (IIRC, that's why
>> we didn't have a 2.0 release last year?)
>>
>>
> I agree we don't need to let this delay a 2.0 release. If the desired
> changes are ready, they can make it in to 2.0. If they're not, then they'll
> get in 2.1 (or 3.0, if necessary).
>
> We didn't have a 2.0 last year, because there were no compelling changes
> requiring, or benefiting from, deprecation removals, and there was a strong
> desire to retain backwards-compatibility with earlier releases, so there
> were no changes which would have required a semver name bump. I don't think
> it was delayed because of API additions. But, I could be mis-remembering. I
> don't think it's critical.

Agreed. I was thinking about 3.0 timeframe. I don't think 2.0 needs to 
be held up by this stuff. I'm more looking for thoughts on how we can 
approach this in a tenable manner than a patch. I honestly don't know of 
how to best handle this.

Is it thinking about these new additions as "versioned" APIs? Like, SKVI 
v1, v2, v3 and then handling this in code in that manner (similar to how 
we do RFile now)? I'm sure smarter people than myself have done 
something well explained/understood. I'm just not sure what this is :)

Mime
View raw message