Ben Manes

We let Gradle perform the version sorting and comparison, so you might have to ask them to include it in their resolution order. The [maven-metadata.xml](https://repo1.maven.org/maven2/io/r2dbc/r2dbc-bom/maven-metadata.xml) does show `SR8` as the...

double checking and I do see `-RELEASE` > `-SRx`. That's likely to be the case in Maven's version plugin, which makes their versioning conventions bad. They should follow the Maven...

You can use a `resolutionStrategy` to reject versions, but passes each candidate in order and means you'll have to reject `RELEASE`. Otherwise you'll have to bring this up to the...

It's hard to say. Since we defer to Gradle's dependency management it is a bit hidden from us. This can sometimes occur due to the Gradle cache, where `--refresh-dependencies` forces...

Sorry that I missed this ticket twice. We scan every configuration's dependencies which these are not included in. The docs imply that they might be mapped into Dependency Constraints, which...

... or accidentally disabled? If no output is specified (text, json, xml) then the results would be discarded and the task becomes useless.

From reading the code, if set to null explicitly. However above that it seems to print the report as `null` is an instance of nothing. https://github.com/ben-manes/gradle-versions-plugin/blob/4ef630704cc7db03462dcb04076f83841946dd4e/src/main/groovy/com/github/benmanes/gradle/versions/updates/DependencyUpdatesReporter.groovy#L85-L94

okay, sounds good. PR welcome.

I suppose if you can detect that the dependency is from your bom, a resolutionStrategy could reject any version except the provided currentVersion.

Thanks for the detailed analysis! Gradle 4.6+ has really made it a bit more painful for us, as we've tried really hard to defer to the build tool's resolution and...