The idea actually was that a new client can never be 100% supported, since a
user could use it accessing new features that the server does not
understand.The reverse is always possible, since the old client can expose
anything new unduly we can always upgrade the server as old as it doesn't break
the old client.
Supporting both ways is too limiting I think, at least for minor version. For
example we might want to add a *new* RPC.As long as we only support old client
with new servers we can do that. In any other combination that would not (as
easily) possible.
That's why I phrased it only that way in my version proposal.
For patch releases it's reasonable to support it both ways.The book is
currently unavailable from the HBase site, so I can't check the exact wording
we ended up with.
-- Lars
From: Nick Dimiduk <[email protected]>
To: hbase-dev <[email protected]>
Sent: Wednesday, March 4, 2015 4:49 PM
Subject: Re: Client-Server wire compatibility?
I believe your posted example is intended to be supported. There's no
enforcement, for instance, that the master is upgraded before all RS's.
On Wed, Mar 4, 2015 at 4:06 PM, Matteo Bertozzi <[email protected]>
wrote:
> the book (http://hbase.apache.org/book.html#hbase.versioning)
> talks about "only allow upgrading the server first" to use new APIs.
>
> what about a new client talking to an old server for "old" operations?
> For example: If I have a 1.1 client, can I ask a 1.0 server to create a
> table?
>
