[
https://issues.apache.org/jira/browse/HBASE-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14274491#comment-14274491
]
Enis Soztutar commented on HBASE-12808:
---------------------------------------
bq. what if we just had a weekly (or nightly) Jenkins job for each branch that
ran this script between the first release of that branch and the tip? That way,
we get away from needing a unit test that needs to be maintained (and which
would only add to how long the CI tests already go), but still have better
granularity when something breaks compatibility than just checking at release
time.
The problem with the jenkins job is that nobody will look at the report
regularly. Instead if we can make it a part of hadoopqa process that might be
acceptable. master build can create the report against whatever the stable
build is annotated with and report on the new breaking changes. Depending on
where the patch will go (master, branch-1, etc) committers can make a judgement
call on that.
bq. In that case, we might get false positives (i.e. for methods that are
actually InterfaceAudience.Private within an InterfaceAudience.Public class),
but we could filter those out with our own ignore list in automation
There are two cases. Individual methods and subclasses within
InterfaceAudience.Public classes. If we can filter those out from the report it
should be fine.
> Use Java API Compliance Checker for binary/source compatibility
> ---------------------------------------------------------------
>
> Key: HBASE-12808
> URL: https://issues.apache.org/jira/browse/HBASE-12808
> Project: HBase
> Issue Type: Improvement
> Components: test
> Reporter: Dima Spivak
> Assignee: Dima Spivak
> Attachments: HBASE-12808_v1.patch, HBASE-12808_v2.patch,
> HBASE-12808_v3.patch
>
>
> Following [~busbey]'s suggestion in HBASE-12556, I've spent some time playing
> with the [Java API Compliance
> Checker|http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker]
> and think it would be a great addition to /dev-support. I propose that we use
> it to replace the JDiff wrappers we currently have there (since it does what
> JDiff does and more), and look into putting up automation at
> builds.apache.org to run the tool regularly (e.g. latest release of a
> particular branch vs. latest commit of that same branch).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
