You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ponomarenko Andrey <an...@yandex.ru> on 2016/06/04 14:19:17 UTC
Binary compatibility report
Hello,
I've just prepared the report on backward compatibility for the Commons IO library (BC \u2014 binary compatibility, SC \u2014 source compatibility): http://abi-laboratory.pro/java/tracker/timeline/commons-io/
The report is generated daily by the japi-compliance-checker and japi-tracker tools:
https://github.com/lvc/japi-compliance-checker (generates individual reports for particular versions of the library)
https://github.com/lvc/japi-tracker (generates the timeline report)
I can add more libraries to the tracker if somebody is interested (just reply this Email with the list of library names to add). Current list of maintained libraries: http://abi-laboratory.pro/java/tracker/
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Binary compatibility report
Posted by Stian Soiland-Reyes <st...@apache.org>.
I think one advantage is that this timeline output shows all the registered
versions, while Clirr is just for the "previous" version (?). Perhaps it is
also more user-friendly presentation?
On 5 Jun 2016 7:59 a.m., "Benedikt Ritter" <br...@apache.org> wrote:
> How would that be different from Clirr?
>
> Gary Gregory <ga...@gmail.com> schrieb am So., 5. Juni 2016 um
> 03:06:
>
> > I would be neat to turn this into a Maven plugin that generates a report
> as
> > part of the generated site.
> >
> > Gary
> >
> > On Sat, Jun 4, 2016 at 7:19 AM, Ponomarenko Andrey <
> > andrewponomarenko@yandex.ru> wrote:
> >
> > > Hello,
> > >
> > > I've just prepared the report on backward compatibility for the Commons
> > IO
> > > library (BC — binary compatibility, SC — source compatibility):
> > > http://abi-laboratory.pro/java/tracker/timeline/commons-io/
> > >
> > > The report is generated daily by the japi-compliance-checker and
> > > japi-tracker tools:
> > >
> > > https://github.com/lvc/japi-compliance-checker (generates individual
> > > reports for particular versions of the library)
> > > https://github.com/lvc/japi-tracker (generates the timeline report)
> > >
> > > I can add more libraries to the tracker if somebody is interested (just
> > > reply this Email with the list of library names to add). Current list
> of
> > > maintained libraries: http://abi-laboratory.pro/java/tracker/
> > >
> > > Thank you.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
Re: Binary compatibility report
Posted by Benedikt Ritter <br...@apache.org>.
How would that be different from Clirr?
Gary Gregory <ga...@gmail.com> schrieb am So., 5. Juni 2016 um 03:06:
> I would be neat to turn this into a Maven plugin that generates a report as
> part of the generated site.
>
> Gary
>
> On Sat, Jun 4, 2016 at 7:19 AM, Ponomarenko Andrey <
> andrewponomarenko@yandex.ru> wrote:
>
> > Hello,
> >
> > I've just prepared the report on backward compatibility for the Commons
> IO
> > library (BC — binary compatibility, SC — source compatibility):
> > http://abi-laboratory.pro/java/tracker/timeline/commons-io/
> >
> > The report is generated daily by the japi-compliance-checker and
> > japi-tracker tools:
> >
> > https://github.com/lvc/japi-compliance-checker (generates individual
> > reports for particular versions of the library)
> > https://github.com/lvc/japi-tracker (generates the timeline report)
> >
> > I can add more libraries to the tracker if somebody is interested (just
> > reply this Email with the list of library names to add). Current list of
> > maintained libraries: http://abi-laboratory.pro/java/tracker/
> >
> > Thank you.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: Binary compatibility report
Posted by Gary Gregory <ga...@gmail.com>.
I would be neat to turn this into a Maven plugin that generates a report as
part of the generated site.
Gary
On Sat, Jun 4, 2016 at 7:19 AM, Ponomarenko Andrey <
andrewponomarenko@yandex.ru> wrote:
> Hello,
>
> I've just prepared the report on backward compatibility for the Commons IO
> library (BC — binary compatibility, SC — source compatibility):
> http://abi-laboratory.pro/java/tracker/timeline/commons-io/
>
> The report is generated daily by the japi-compliance-checker and
> japi-tracker tools:
>
> https://github.com/lvc/japi-compliance-checker (generates individual
> reports for particular versions of the library)
> https://github.com/lvc/japi-tracker (generates the timeline report)
>
> I can add more libraries to the tracker if somebody is interested (just
> reply this Email with the list of library names to add). Current list of
> maintained libraries: http://abi-laboratory.pro/java/tracker/
>
> Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Binary compatibility report
Posted by Ponomarenko Andrey <an...@yandex.ru>.
Hello,
Thanks for reporting this bug. It's fixed for now.
The yellow background is used if there is at least one compatibility warning found or compatibility rate is between 90 and 100 percents. Orange color is used when compatibility rate is between 80 and 90 percents. Red color is used when the rate is less than 80 percents and for removed symbols. Blue color is used for added symbols.
The rules that are used to determine compatibility problems are taken from http://wiki.eclipse.org/Evolving_Java-based_APIs_2
The Clirr tool can't identify at least two compatibility problems:
* if a method became abstract in the class (may lead to InstantiationError exception)
* if a method became static/non-static (may lead to NoSuchMethodError exception)
... and two compatibility warnings:
* change of a final field value (e.g. string value from "A" to "B")
* added/removed exceptions of a method
Other differences from Clirr:
* report format
* 4 severity levels (High/Medium/Low/Safe vs ERROR/WARNING/INFO)
* counts affected symbols and compatibility rate
* separates binary- and source-compatibility problems in the report
* shows exact compiler error message, so one can google the report and understand that the issue was happened due to incompatibility of versions
* lists added/removed symbols separately from other problems
* has an option to filter annotated/deprecated classes and methods
* detects renamed fields
* and more ...
Thank you.
05.06.2016, 11:31, "sebb":
> On 4 June 2016 at 15:19, Ponomarenko Andrey wrote:
>> �Hello,
>>
>> �I've just prepared the report on backward compatibility for the Commons IO library (BC \u2014 binary compatibility, SC \u2014 source compatibility): http://abi-laboratory.pro/java/tracker/timeline/commons-io/
>
> Thanks for the links.
>
> However I found it difficult to understand the output.
> For example, why are some backgrounds green and some yellow?
>
> Also, what are the rules that are used to determine whether or not a
> change affects compatibility?
> How do these compare with Clirr?
>
> I think there's a bug:
>
> The low level warning here
>
> http://abi-laboratory.pro/java/tracker/compat_report/commons-io/1.4/2.0/8be39/bin_compat_report.html#Type_Problems_Low
>
> says that it was caused by the change:
>
> "Added super-class java.lang.Object."
>
> That's not possible as a change.
>
>> �The report is generated daily by the japi-compliance-checker and japi-tracker tools:
>>
>> �https://github.com/lvc/japi-compliance-checker (generates individual reports for particular versions of the library)
>> �https://github.com/lvc/japi-tracker (generates the timeline report)
>>
>> �I can add more libraries to the tracker if somebody is interested (just reply this Email with the list of library names to add). Current list of maintained libraries: http://abi-laboratory.pro/java/tracker/
>>
>> �Thank you.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Binary compatibility report
Posted by sebb <se...@gmail.com>.
On 4 June 2016 at 15:19, Ponomarenko Andrey <an...@yandex.ru> wrote:
> Hello,
>
> I've just prepared the report on backward compatibility for the Commons IO library (BC — binary compatibility, SC — source compatibility): http://abi-laboratory.pro/java/tracker/timeline/commons-io/
Thanks for the links.
However I found it difficult to understand the output.
For example, why are some backgrounds green and some yellow?
Also, what are the rules that are used to determine whether or not a
change affects compatibility?
How do these compare with Clirr?
I think there's a bug:
The low level warning here
http://abi-laboratory.pro/java/tracker/compat_report/commons-io/1.4/2.0/8be39/bin_compat_report.html#Type_Problems_Low
says that it was caused by the change:
"Added super-class java.lang.Object."
That's not possible as a change.
> The report is generated daily by the japi-compliance-checker and japi-tracker tools:
>
> https://github.com/lvc/japi-compliance-checker (generates individual reports for particular versions of the library)
> https://github.com/lvc/japi-tracker (generates the timeline report)
>
> I can add more libraries to the tracker if somebody is interested (just reply this Email with the list of library names to add). Current list of maintained libraries: http://abi-laboratory.pro/java/tracker/
>
> Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org