accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 25 Nov 2014 20:48:35 GMT
On Tue, Nov 25, 2014 at 2:39 PM, Christopher <ctubbsii@apache.org> wrote:

> On Tue, Nov 25, 2014 at 3:35 PM, Sean Busbey <busbey@cloudera.com> wrote:
>
> > On Tue, Nov 25, 2014 at 2:16 PM, Keith Turner <keith@deenlo.com> wrote:
> >
> > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <busbey@cloudera.com>
> > wrote:
> > >
> > > > > altering the public API (as a standalone change)
> > > >
> > > > I am very conservative about changes to our public API. I have had to
> > > write
> > > > code that works across Accumulo versions and even when only working
> > with
> > > > the public API is it painful on almost every release. I have also
> seen
> > > > plenty of cases where deployments of Accumulo lag behind version
> > changes
> > > > because of this same issue.
> > > >
> > > > I fully support that major version changes are there for us to break
> > > APIs.
> > > > That doesn't mean that such breakage doesn't have a high cost that
> > needs
> > > to
> > > > be weighed carefully.
> > > >
> > > > In general, for me to be positive on an API change there needs to be
> a
> > > > compelling improvement or a correctness issue. For me, that
> correctness
> > > >
> > >
> > > Which API changes are you more concerned about?  Deprecating two
> methods
> > > and/or the addition of a new method?
> > >
> > >
> > They're the same as far as I'm concerned. The intention is clearly to
> move
> > to the new method. The deprecation cycle will help when I need to have a
> > client that spans 1.6 and 1.7. It won't help when I need to span 1.6 to
> > whatever the version is where the deprecated stuff is removed.
> >
> >
> I'm perfectly content and willing to leave those methods un-deprecated, and
> provide longer API support for the older methods, if that's the main
> concern.
>


How about if we push this change in the API out to the client reworking in
2.0? Everything will break there anyways so users will already have to deal
with the change.

-- 
Sean

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message