[
https://issues.apache.org/jira/browse/HBASE-12556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221855#comment-14221855
]
Sean Busbey commented on HBASE-12556:
-------------------------------------
My concern is that we'll be ad-hoc recreating compatibility checks that others
have spent way more effort maturing.
For example, ATM we don't take into account
# sub-class-level audience or stability annotations
# source incompatible changes to generics
# changes to members
# incompatible changes to extends / implements
I realize this is a rough draft and we can build these things, but why do it
ourselves when we can build on the work of others?
We can achieve the automation by expanding on the scripts used to verify
patches pre-commit and post-integration with trunk.
We can automate it to individual developers builds either by gymnastics to make
java api compliance checker work or use something that's already Maven friendly
like [Clirr|http://mojo.codehaus.org/clirr-maven-plugin/index.html].
Adding or changing InterfaceAudience annotations is already us explicitly
changing our API. Reviewers _should_ be treating it carefully. If they're not,
making them do one additional step isn't going to fix that.
> Create a golden file for testing client API source/binary compatibility
> -----------------------------------------------------------------------
>
> Key: HBASE-12556
> URL: https://issues.apache.org/jira/browse/HBASE-12556
> Project: HBase
> Issue Type: Sub-task
> Components: Client
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 0.99.2
>
> Attachments: hbase-12556-wip.patch
>
>
> [~lhofhansl] had a suggestion (in some other jira I forgot) for doing a
> golden file for the HBase API so that we can compare between releases to
> ensure that we are keeping source and binary compatibility as defined in this
> document :
> https://docs.google.com/document/d/1p5pP7v2OuzSSaomK2S2v7sfKky1Hex6OqwsJO0sZTUY/edit
>
> I think we can generate a file, commit it to the repo, and create a unit test
> to check whether any API's are broken. Adding new InterfaceAudience.Public
> interfaces has to modify this file so that it becomes an explicit decision.
> The downside is that we have to modify the file every time we add a new API,
> but it should be fine since it will force us to think more before committing
> to supporting new interfaces within the same major versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
