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:35:59 GMT
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.


-- 
Sean

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