accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 14:24:15 GMT
On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey <> wrote:

> On Dec 4, 2014 6:55 AM, "Josh Elser" <> 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.

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