[
https://issues.apache.org/jira/browse/HBASE-12556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-12556:
----------------------------------
Attachment: hbase-12556-wip.patch
Here is a rough idea for what I had in mind. A simple class to generate the
golden file, a unit test to check against this file, and a sample golden file
in simple text format.
If a patch adds a new API for example, the test will fail, and the author will
be responsible to re-create the golden file again (containing the new
interfaces) which will make it explicit. If an interface gets deleted, or
changed, this UT will catch it.
RM's can also do a simple diff against this file to double-check changes
between releases.
Let me know what you guys think.
> 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)
