hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: On coprocessor API evolution
Date Sat, 17 May 2014 03:56:06 GMT
On Fri, May 16, 2014 at 1:47 AM, Stack <stack@duboce.net> wrote:

> I had just read a user mail on the phoenix list where someone thought that
> phoenix had been broken going from 0.98.1 to 0.98.2 (apparently its fine).
> Lets write up agreement.  We've talked this topic a bunch.
> 1. No guarantees minor version to minor version?  APIs can be broken any
> time.
> 2. API may change across minor versions but SHOULD not break existing users
> (No guarantees!)?
> 3. API may change across minor versions but WILL not break existing users?
> Any other permutations? (I'm good w/ #2 and #3.  #1 will just make it so no
> one will use CPs).

I would say #3 (WILL NOT) but with the very important detail that the
coprocessor API user must extend one of the abstract classes not using the
interface directly. As Vladimir points out we must have an abstract base
class for every interface to make that possible.

For 1.0 or at least as soon as possible (could be a major undertaking -
what say you all to getting it done?), I'd like to layer an API like that
proposed in HBASE-11125 where we can provide strong compatibility
guarantees at that layer, have the actual hooks implemented in a layer
below, and get away with quite weak guarantees in the lower layer to afford
us freedom to refactor.

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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