hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dima Spivak (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12556) Create a golden file for testing client API source/binary compatibility
Date Tue, 06 Jan 2015 22:39:34 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266893#comment-14266893

Dima Spivak commented on HBASE-12556:

Hey [~enis], I think passing the golden file generated the patch in this JIRA (after stripping
out the method names and types) would be ideal for using the Java API Compliance Checker.
Since I think the use of such a checker, and not just analyzing the list in a unit test (for
the reasons detailed by [~busbey] above) is the way to go, would you be open to committing
the golden file generation and then leaving the analysis to done by HBASE-12808? I've separately
reached out to the developer of Java ACC about adding annotation support, but we could get
this online in no time if we had a way to generate a file with the list of classes to analyze
(since that's already a feature of the tool).

> 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: 2.0.0, 1.1.0
>         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

View raw message