All committers have signed the CLA.

Thank you for the quick and precise feedback.

Most importantly: To reduce the complexity of your changes, it would be great if you could limit this PR to the already supported Maven range syntax, for now ignoring gradle's strict version notation. This should allow you to reuse the existing maven range parsing, it should work without changes to the parser and, unless I missed something, only require a few adaptations in the gradle versioning

The primary driver for this PR was the need for Gradle's strict version notation at my company. It allows us to specify: yes, you can use a newer dependency if you want, but if there are options to choose from, prefer the one specified with the '!!' Unfortunately, this functionality isn’t achievable without adding Gradle’s syntax.

Would your suggested path forward be to first implement Maven-only ranges (using the existing Maven module, which seems feasible), and then add Gradle syntax in a follow-up? If so, is there a way to minimize complexity and avoid lengthy delays? I work part-time (twice a week) and want to ensure this progresses smoothly without causing blockers.

Would your suggested path forward be to first implement Maven-only ranges (using the existing Maven module, which seems feasible), and then add Gradle syntax in a follow-up? If so, is there a way to minimize complexity and avoid lengthy delays? I work part-time (twice a week) and want to ensure this progresses smoothly without causing blockers.

Yes, the suggestion to do it in two iterations was exactly aimed at more efficient reviews: in a first PR focus on already parsed Maven ranges and add the bump strategy + composition of a new satisfying version to the gradle versioning part. In a second PR add ! and to versionLikeSubstring and extend the gradle versioning part with support for strict version definitions.

I've adjusted this merge-request to match the new scope.

Please add a reproduction repo so that your changes can be tested against, incl a dep with regular maven based range and one with a range + strict version enforcement.

Is there a guide on how to do that or a pull request that had the same requirement where I could take a look at?

I did the changes you've suggest, the repro will have to wait until my next workday this week. Thanks for the link!

You may also want to add bump here:

I am trying to get the repro running right now.
The repro repo is here
To verify that my test setup is working correctly i wanted to try the already implemented pin strategy on the main branch first. The weird thing is, that even that doesn't even seem to work. The version update fails due to a wrongly positioned fileReplacePosition:

Have i misconfigured something?
I am running renovate locally using pnpm debug ldt-fweichert/renotave-gradle-repro, nothing unusual there i guess.

Have i misconfigured something? I am running renovate locally using pnpm debug ldt-fweichert/renotave-gradle-repro, nothing unusual there i guess.

Your build.gradle.kts uses Unix line endings, so fileReplacePosition 814 is correct for io.ktor:ktor-server-netty:3.0.0. See https://github.com/renovatebot/renovate/blob/main/docs/development/best-practices.md#windows on how to resolve your CRLF issue.

The bump strategy is working in my reproduction repo - thanks for the quick assistance! Should the documentation be updated to reflect this change somewhere?

needs prettier run

@viceice prettier should be happy now

Does the failed Build / test-success (pull_request) check mean that some tests are failing?

Test failures appear to have been a temporary problem

🎉 This PR is included in version 39.177.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 39.177.0

Your semantic-release bot 📦🚀