Christopher wrote:
On Fri, Aug 26, 2016 at 1:25 PM Sean Busbey<[email protected]> wrote:
On Fri, Aug 26, 2016 at 11:58 AM, Christopher<[email protected]> 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 :)
