Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
References: <57C072B7.7020705@gmail.com> <CAL5zq9YeQVrwR7vM7HO5_orK-ii-HZj_+zqpaUGNWPs-dXcsHA@mail.gmail.com>
 <CAGHyZ6JL1UYF9LamhV7Zy7pcF+u8bMH-Pe9BW1_jgD8q119LnQ@mail.gmail.com>
In-Reply-To: <CAGHyZ6JL1UYF9LamhV7Zy7pcF+u8bMH-Pe9BW1_jgD8q119LnQ@mail.gmail.com>
From: Christopher <ctubbsii@apache.org>
Date: Fri, 26 Aug 2016 17:33:35 +0000
Message-ID: <CAL5zq9a3yv73k5GRKcXONqrabH01-21J=BrkqZR1r6U4a5OC3Q@mail.gmail.com>
Subject: Re: [DISCUSS] How to bring more pluggable interfaces into public API
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=001a113cf70aa740da053afcea22
archived-at: Fri, 26 Aug 2016 17:33:49 -0000

--001a113cf70aa740da053afcea22
Content-Type: text/plain; charset=UTF-8

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.


>
> > On Fri, Aug 26, 2016 at 12:48 PM Josh Elser <josh.elser@gmail.com>
> 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.
>
> --
> busbey
>

--001a113cf70aa740da053afcea22--