accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [DISCUSS] How to bring more pluggable interfaces into public API
Date Fri, 26 Aug 2016 17:24:59 GMT
On Fri, Aug 26, 2016 at 11:58 AM, Christopher <> 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?

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?)

> On Fri, Aug 26, 2016 at 12:48 PM Josh Elser <> wrote:
>> In an >=Accumulo-2.0 world, I think it would be prudent to investigate
>> how we can address this problem to reduce maintenance burden on
>> ourselves and create supported "public API" interfaces for these. I
>> imagine that we could come up with a general approach that provides
>> "guidelines" for how we would handle cases like this in the future.

Another option would be that we expressly make these pluggable parts
"use at your own risk" internals with a weaker compatibility promise
than semver.  We could, for example, label these points as something
that we won't break in a double-dot release (e.g. whatever works in
1.7.0 will work in 1.7.z) but still give ourselves the room to change
them in minor releases.

I primarily mention this because we don't have an established history
for maintaining code lines across major version releases, so I'm
skeptical of things that will force us to increment the version in the
master branch across major #s.


View raw message