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 21:12:55 GMT
On Tue, Nov 25, 2014 at 3:48 PM, Sean Busbey <busbey@cloudera.com> wrote:

> 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.
>
>
Once again, this change does not break anything. I understand wanting to
reserve the deprecation of the old methods until 2.0, but I do not
understand the objection for API additions/improvements in 1.7.0 that has
no impact on existing methods or behavior. Also, since you can only veto
changesets, and not release candidates, I don't see what would stop a
release manager from backporting this changeset to 1.7 prior to its release
if we push it to a 2.0 branch. I don't see why this improvement must be
postponed.

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