> * The developer wants to check if they are compliant, therefore they check > their changes against trunk
Yes. > * 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) Yes. > * 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). Nice to have, but could be done separately. > * 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. Is this different from the Jenkins PR point? > * 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.) Helpful, but one would hope that the dependencies do this on their own. > 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. I'd say we could even just do 2.0 and trunk. [ Full content available at: https://github.com/apache/kafka/pull/5620 ] This message was relayed via gitbox.apache.org for [email protected]
