Detect API compatibility issues

[magro]

There should be an automated mechanism that detects a breaking change of the kryo api (both compile time and runtime issues).

There was already mentioned the https:/jeluard/semantic-versioning project that might help with this. Another idea would be to create a separate projects that depends on kryo (SNAPSHOT) and runs test against it (behaving like a real client).

Related to this, but out of scope of this issue: detecting changes of the serialization format would also be good to have.

[martin-g]

You can check http://mojo.codehaus.org/clirr-maven-plugin/.
We use it in Apache Wicket.

[magro]

@martin-g Great, I'll have a look at it. I played with semantic-versioning but the results were not that promising. Then I tried the Java API Compliance Checker and got good results, here's the report for a comparison of kryo 2.22 and the latest SNAPSHOT as of today: kryo-compat_report_2.22_to_2.23-20131125.093430-23.html.

[romix]

Martin, the results of Java API Compliance Checker look very nice! Cool!

Looking at them, it seems that a few classes related to the FieldSerializer implementation need to be made non-public, so that any changes in them are ignored, as they are not supposed to be used by an client code.

The int to long change for a "total" method was discussed on the mailing list and there was an issue for it.

[magro]

@romix Sounds good to change public non-api classes to non-public. We could also exclude classes from the comparison that are public but not meant to be part of the public api.

Just for the record: regarding the Output.total change I found issue #142 that motivated this.

[magro]

I just created a new compat report comparing 2.22 and 2.23-20131201.010510-27, after minlog and objenesis are no longer sharded.

[romix]

Cool!
Could you also try to create a report comparing 2.21 (or even 2.20) and our latest trunk? The reason for this request: in 2.22 we added objenesis and minlog and now we removed it. It resulted in a lot of changes being detected by this tool. But most of them are not real changes, as virtually nobody migrated to 2.22 and started using shaded names... Therefore comparing something <=2.21 and current trunk could be also interesting and make more sense.

[magro]

I've created reports for consecutive versions starting from 2.17 and for * to 2.23-SNAPSHOT (jars loaded from maven central). 2.18 is missing because it was not released to maven central.
I've pushed reports to a separate repo kryo-compat-reports. When you're viewing a report file in raw mode you can replace raw.github.com with rawgithub.com, e.g. change https://raw.github.com/magro/kryo-compat-reports/master/2.17_to_2.19.html to https://rawgithub.com/magro/kryo-compat-reports/master/2.17_to_2.19.html.