[
https://issues.apache.org/jira/browse/HBASE-19535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294075#comment-16294075
]
Chia-Ping Tsai commented on HBASE-19535:
----------------------------------------
Our doc has the following explanation.
{code}
Client Binary compatibility
Client code written to APIs available in a given patch release can run
unchanged (no recompilation needed) against the new jars of later patch
versions.
Client code written to APIs available in a given patch release might not
run against the old jars from an earlier patch version.
Example: Old compiled client code will work unchanged with the new jars.
If a Client implements an HBase Interface, a recompile MAY be required
upgrading to a newer minor version (See release notes for warning about
incompatible changes). All effort will be made to provide a default
implementation so this case should not arise.
{code}
The trouble, for example, is that we can't provide the bc for user if we want
to add new method to {{TableDescriptor}} in patch/minor release because the
custom {{TableDescriptor}} must be modified also (although it is rare that
users have custom {{TableDescriptor}} impl I think).
> Introduce a new annotation to say there is no BC guarantee in the inheritance
> -----------------------------------------------------------------------------
>
> Key: HBASE-19535
> URL: https://issues.apache.org/jira/browse/HBASE-19535
> Project: HBase
> Issue Type: Task
> Reporter: Chia-Ping Tsai
> Priority: Critical
> Fix For: 2.0.0
>
>
> We have added many Public "read-only" interface in 2.0 to save user from the
> dangerous operations. For example, TableDescriptor, ColumnFamilyDescriptor,
> Region, Store, etc. However, this change make us be hard to enhance these
> interface (ie. add the new APIs) because the BC will be broken for the user
> having the subclass of these interfaces. In contrast with Cell, Filter, and
> coprocessor, these new interfaces are NOT designed to be a extendable class
> for user but we have no explicit caveat. As I see it, it is necessary to
> introduce an new annotation to explicitly say "you CAN extend this Public
> class with the BC guarantee". On the other hand, user should not extend the
> Public classes which don't have the such annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
