@ijuma A couple of questions to clarify the use-case. So I was presuming that generally there are 5 use-cases. - The developer wants to check if they are compliant, therefore they check their changes against trunk - We want to enable a check in the PR Jenkins jobs that check PRs if they are compliant (so enforce binary compatibility rule in minor and patch/maintenance releases) - We want to compare random releases to see how did they change from version to version to evaluate how risky it is for users to migrate (or just compare releases just for fun). - When creating patches it is a good thing to see if the patch is good and doesn't break binary compatibility, so let's check against a released version that is being patched. - When upgrading dependencies we'd like to see if we're breaking binary compatibility in them. (I don't see this generally as a big problem but might be an issue though.)
I'm curious if you think we'd aim for these changes or do we need something else? Also I managed to figure out a way for downloading dependencies (it doesn't seem to be too complex afterall), but it requires a bit more time to implement a well-working solution. Also I'll limit the minimum version to be 0.11.0.0 for version downloads. The reason is that certain projects are added during the life of Kafka and going back too much would overcomplicate the whole checker (as I need to add exceptions for certain projects etc.) and I don't see the value in those situations. I think it is not often a use-case when such an old version is asked. And if it is, we can fall back to "compile then compare" instead of "download and compare". If needed I can do it after more important things are ready. [ Full content available at: https://github.com/apache/kafka/pull/5620 ] This message was relayed via gitbox.apache.org for [email protected]
