@ijuma answeing your question: yes it is a subclass of the PR point technically 
not different.

I've reworked this pretty much and accomodated for most of these use cases 
(except the dependency checking).
Does the following by default.
- It compares the last release with the current branch that we're building on. 
This is good for a generic development activity and doesn't require any extra 
time as it downloads the last release from the configured maven repos.
- it is part of the `check` lifecycle step, so whenever a user runs a `gradle 
build` or `gradle check` it'll run after the `assemble` task.
- You can run it against two arbitrary branches / tags and even released 
versions. The git references must be local, otherwise it won't work.
- The release download only works for Kafka 2.0.0+. If somebody adds a new 
project which is not released yet, then the download will fail (and therefore 
it fails the build). The build detects though if the source or target 
references are released versions or not (and therefore has to be built) but if 
a released version doesn't contain a project (such as 0.7 didn't contain 
connect) it'll fail when downloading that. This is an unsolved problem as it 
might be nicer to maybe ignore these but I didn't spend too much time with this 
as projects aren't added that often and I tried to exclude any "examples" and 
"system-test" project (that might be added more frequently). Anyway, I think 
this is a bridge that we need to cross when we're there.
- By default it only shows incompatibilities but this can be set through the 
`onlyIncompatible` gradle property.
- By default it doesn't fail the build in any circumstances but it can be set. 
There are three flags for this: `failOnBinaryIncompatibility`, 
`failOnSourceIncompatibility` and `failOnSemanticIncompatibility`. The first 
two I think straight enough but the third triggers the mode which we actually 
need. So it will enable failing the build if there is a binary incompatible 
change between the source and the target if they are minor or patch 
(maintenance) releases. The reason why I didn't enable this by default is that 
there is already a bunch of incompatibilities in 2.1 and it would immediately 
fail the build. I think it would make sense to keep it this way until releasing 
2.1 and then switching the default from `false` to `true` on this when bumping 
the version.
- I've added an extra gradle property called `lastRelease` that must be updated 
whenever the version is bumped after a release.

[ Full content available at: https://github.com/apache/kafka/pull/5620 ]
This message was relayed via gitbox.apache.org for [email protected]

Reply via email to