[
https://issues.apache.org/jira/browse/HBASE-12556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221842#comment-14221842
]
Enis Soztutar commented on HBASE-12556:
---------------------------------------
I would like to make checking of source compatibility automated. And also, I
want to make adding new Public APIs explicit so that authors and reviewers
think twice about adding new stuff that we have to maintain over the long term.
jdiff is great, but it is manual (for now) and it is only done at the time of
the release candidate (which is too late I think).
That's why I think we should have an internal unit test for testing this. I
already have a patch for creating and checking golden files for the client API
without any more dependencies (using HBASE-10671 tests). It checks for source
compat, and it checks class names with "class" or "interface" prepended. I am
not sure whether that it is enough for binary compat check (or we should mark
abstract classes as well). In cases where this tool creates false negatives,
the author can regenerate the file, and review can verify that the changes are
in fact compatible I think.
Let me attach what I have now. It is not done yet, but gives an idea of what I
am thinking.
> 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
>
>
> [~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)
