accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 16:15:54 GMT
I would very much like the new API to be something that we think has the
right shape, ignoring implementation details. Otherwise we end up with
something like a mapred/uce split and that still has people confused about
which is the right one.

On Thu, Dec 4, 2014 at 8:46 AM, Josh Elser <josh.elser@gmail.com> wrote:

> Can we reach a compromise here that the general idea that had been
> presented will be followed and, of such an impasse is found in supporting
> the old api, we will have another discussion on what to do when we actually
> have a concrete problem?
>
> I feel like we can't get around this issue otherwise since it's a
> hypothetical worry.
>
> Planning on both APIs to be around saves us from having to get the new api
> 100% right the first time around (because we all know the current api still
> isn't there :)).
> On Dec 4, 2014 9:24 AM, "John Vines" <vines@apache.org> wrote:
>
> > On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey <busbey@cloudera.com> wrote:
> >
> > > On Dec 4, 2014 6:55 AM, "Josh Elser" <josh.elser@gmail.com> wrote:
> > > >
> > > > (I was still confused so I just chatted with John on the subject of
> his
> > > -1)
> > > >
> > > > He was under the impression that it would not be feasible to leave
> the
> > > existing 1.X APIs in place with the creation of the 2.0 APIs; whereas,
> I
> > > had assumed that this wouldn't be an issue.
> > > >
> > > > He brought up the issue of how we plan to handle exceptions in the
> new
> > > API which, would very likely, include changes to the Thrift APIs as
> well.
> > > If this is the case, we'd now have to support the 1.X API (while it
> > existed
> > > as deprecated) as well as the new 2.0 API. This would likely affect how
> > we
> > > actually want 2.0 API to operate.
> > > >
> > > > This all kind of boils down to confusion over whether or not there is
> > any
> > > compatibility between 1.x and 2.0. If 2.0 is a clean break from 1.x,
> this
> > > thread is pointless. Otherwise, we risk not getting the APIs we really
> > > want.
> > > >
> > > > Does this help clarify the concern?
> > > >
> > >
> > > One way to address that kind of concern would be to only support the
> 1.x
> > > APIs via an optional different end point.
> > >
> > > We obviously don't have enough information at this point to evaluate
> how
> > > much such a separation would take to implement nor how maintainable it
> > > would be.
> > >
> > > But there at least seems to be a way to work through that issue if it
> > comes
> > > up.
> > >
> >
> > I hope so. But until we have a new API fully implemented that we're
> content
> > with, I don't think we should have any guarantees made about
> compatibility
> > of the 1.x API, just in case we end up hitting an insurmountable issue.
> >
>

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