version 0.7.0 directly (and only partially) upgrades version numbers in libraries

[nkiesel]

I have a gradle/libs.versions.toml which contains (among other entries)

[versions]
mockito = "4.8.0"

[libraries]
mockito-core = { module = "org.mockito:mockito-core", version.ref = "mockito" }
mockito-junit-jupiter = { module = "org.mockito:mockito-junit-jupiter", version.ref = "mockito" }

When running ./gradlew versionCatalogUpdate, it says:

The following dependencies have later milestone versions:

• org.mockito:mockito-junit-jupiter [4.8.0 -> 4.8.1]
  https://github.com/mockito/mockito

but I end up with

[versions]
mockito = "4.8.0"

[libraries]
mockito-core = { module = "org.mockito:mockito-core", version.ref = "mockito" }
mockito-junit-jupiter = "org.mockito:mockito-junit-jupiter:4.8.1"

[hvisser]

If the core dependency did not update, this is expected. Only the junit-jupiiter dependency changed version, so it would not be correct to bump everything in the group. In stead, the upgraded dependency is updated separately.

If core also gets updated to the same version then both dependencies would be added to the group again.

[nkiesel]

core is updated as well (since 3 days). And you are saying that if they really update in stages, then at the end I end up with

[versions]
mockito = "4.8.1"

[libraries]
mockito-core = { module = "org.mockito:mockito-core", version.ref = "mockito" }
mockito-junit-jupiter = { module = "org.mockito:mockito-junit-jupiter", version.ref = "mockito" }

(i.e. it will replace the hard-coded "4.8.1" in mockito-junit-jupiter again with a ref?) How would it even know that the 2 libs are connected after it eliminated the ref?

[hvisser]

I'm saying that if de versions plugin does not see an update for core, this behaviour is correct. When core is updated, the plugin will try to group the versions again for you and reuse any existing group that exists. This is based on the maven group. You can also see this if you update core manually and then run the format task, without checking for updates.

[nkiesel]

I restored the original config and rerun the update, and the behavior is unchanged: mockito-core:4.8.1 is available on mavenCentral, but not found. That seems to be an issue in itself.

But I really don't like the "break version groups" approach. In many cases, this is chosen because all the libs depend on each other and thus should stay at the same version. I thus would rather keep all the libs consistently on the old version until the whole group can be updated. Would be much nicer to get a warning like "cannot upgrade mockito version from 4.8.0 to 4.8.1 because org.mockito:mockito-core:4.8.1 is not available" in such a case.

[hvisser]

Unfortunately there's really no way to know if a dependency is updated in tandem with other dependencies in the group so I don't think there would be a reliable way to show that error.

If you don't get the update, it might be that the dependencies are cached and the versions plugin is not reporting it. You can try running with --refresh-dependencies to see if that fixes that maybe. You can also check the report.json generated by the versions plugin to see if it's included in any of the sections.

If you have a project that reproduces this I'm happy to take a look, maybe there's a specific reason why that version is not found or used by the versions plugin in this case.

[nkiesel]

After --refresh-dependencies it worked again (upgrading versions to 4.8.1). I will report back here once I find another example.

groups: I only re-use version refs in libs for those which are closely related and must advance in sync. Thus, I would never want them to be broken up (I would instead then create 2 different groups with separate versions). But I understand that this is my personal preference. Perhaps we could have an option for this?

[hvisser]

Great! Keep in mind that this usually does not happen unless a project splits off an artifact that doesn't follow a common version or you hit some kind of fluke due to the dependency not being published or visible yet on Maven Central (or in your case most likely cached somewhere). In that sense this is a bit of an edge case and I'm not sure if that justifies adding a setting.

In stead of a setting to disable the behaviour or breaking/creating version groups, I'd lean towards printing out a sort of summary when a group is created/changed so that you can better understand why the plugin did what it did. Then, you can always take action yourself like just reverting and bumping the version group, which should also have worked in your case. Would that make sense?

[hvisser]

Sorry to counter proposal your feature request for the second time by the way, this is not intentional, appreciate the feedback ofc!

[Nek-12]

I'm facing the same issue here. The task does not update dependencies correctly and does not recognize many new versions, even downgrading some on execution.
P.S. I've disabled xml reports in ben-manes/gradle-versions-plugin task because of ben-manes/gradle-versions-plugin#706

[hvisser]

Did you disable those reports in such a way that the json report is being generated? The plugin needs the json report to function, so it might be that it's not generated and therefore no updates are processed. A clean build will yell at you, but you might have a stale report.json around still.

[Nek-12]

Seems like I do have a stale report and I have also disabled json by accident, thanks, I think enabling it should solve the issue

[Nek-12]

I think we can close this if we add a note about this behavior to the readme

[hvisser]

I think we can close this if we add a note about this behavior to the readme

The dependency plugin configuration is not related to the issue that was initially created.