[
https://issues.apache.org/jira/browse/HBASE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294127#comment-14294127
]
Sean Busbey commented on HBASE-12932:
-------------------------------------
I think InterfaceStability changes are fine pre-1.0. post-1.0 I think going
from Stable -> Evolving needs to be on major version, and Evolving -> Unstable
needs to be on minor, since those are the version boundaries where an annotated
class would change.
On the general matter of Interface changes, I think adding methods to
interfaces is fine if we work internally to do graceful fallback or service
degredation. For example, the interface changes that happened to some of the
coprocessor apis in HBASE-12522. That is to say, pesonally I'm concerned about
making sure binaries run more than theoretical binary compatibility. This is in
opposition to our stated compatibility listing though, which specifies source
compatibility.
It's really hard to guess what downstream users will do with our code; I'd like
to stick with our promises once they're made. If we want to evolve these things
in the face of our promises, we should do a clean up that ensure there are no
interfaces marked stricter than Public/Evolving.
> [0.98] Change the interface annotation of HConnection from Public/Stable to
> Public/Evolving
> -------------------------------------------------------------------------------------------
>
> Key: HBASE-12932
> URL: https://issues.apache.org/jira/browse/HBASE-12932
> Project: HBase
> Issue Type: Task
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Fix For: 0.98.10
>
> Attachments: HBASE-12932-0.98.patch
>
>
> See the tail of HBASE-12859. Lars wants to add methods to HConnection. I
> suggest not because HConnection has Public/Stable annotation. Enis then says:
> {quote}
> We do not differentiate or explicitly document this, but my understanding of
> most of our InterfaceAudience.Public is for consumption, not for extending or
> implementing interfaces (except for some coprocessor cases). So I think we
> should be free to add new methods in Admin, Connection, etc in minor
> versions. I would say that in patch versions we should not do such changes.
> Maybe we can do a base classes as a convenience, but still with no guarantees.
> {quote}
> to which I reply:
> {quote}
> Shrug. So the Public/Stable annotation just means "keep this interface
> around, don't worry about changes that will break an implementor?" . Then
> what would Public/Evolving (or Unstable) mean as difference? Do we have what
> the annotations mean documented somewhere? This point didn't come up in a
> review when I backported client pushback, so now we have
> StatisticsHConnection. If it's ok to add methods to HConnection I would like
> to sink the 0.98.10 RC that has this change and fix it with a new patch/issue.
> {quote}
> I'm not sure what others think, but if we change the annotation of
> HConnection to Public/Evolving then it would make sense to allow methods to
> be added.
> I will open a subtask of this issue to nuke StatisticsHConnection if/once the
> annotation is changed. I would also sink the current 0.98.10 RC that has
> StatisticsHConnection in it so it never sees the light of day.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
