accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] ACCUMULO-3176
Date Tue, 25 Nov 2014 20:39:52 GMT
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.

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