accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 14:46:04 GMT
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