feat(replacements): add replacements:gradle-wrapper-validation-action

[mueller-ma]

Changes

See Readme at https://github.com/gradle/wrapper-validation-action for more information.

Context

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

We normally don't want to do "replacements"
When the change is breaking. An alternative here is to met the user update to v3 and then migrate them

[mueller-ma]

Now the user needs to update to version 3 before the replacement happens.

[rarkins]

Is the intent to allow either 3 or e.g. 3.2.10? and not e.g. 3.2?

[HonkingGoose]

The code started with:

        "matchCurrentVersion": "3",

I asked if that would match all possible versions in the 3 range:

• feat(replacements): add replacements:gradle-wrapper-validation-action #31645 (comment)

Our developers docs list the rules for replacement presets:

Rules for replacement presets

1. Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible matchCurrentVersion constraint
2. If no compatible replacement upgrade is possible, it's acceptable to propose an incompatible one (e.g. a major version upgrade)
3. Replacements should update the user to the first recommended version of the new dependency and not include any new changes - whether breaking or not - if they can be avoided, in short: pin the new version

If possible, replacement presets should give the user a replacement version that is functionally identical to the last version under the old name.
We only want a user's tests to fail because of broken references to the old package name, and not because the maintainer(s) changed the behavior of the package.

The key phrase in the docs is:

Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible matchCurrentVersion constraint

So then the question is, is just being on any version 3 of the program good enough for a user to quickly merge the replacement PR? Or does the user need to be on the last version of the old package?

[mueller-ma]

So then the question is, is just being on any version 3 of the program good enough for a user to quickly merge the replacement PR? Or does the user need to be on the last version of the old package?

@HonkingGoose I think it's good replace the dependency when on any version 3.

[rarkins]

OK but should it be "matchCurrentVersion": "/^3\\.", ? Note the ^ to enforce it at the start of the line, and the mandatory . (assumes that there will always be some precision to the version and not just `"3" itself, is that safe?)

[mueller-ma]

The version can be v3 or v3.5.0:

• https://github.com/mueller-ma/Coffee/blob/main/.github/workflows/build.yml#L27
• https://github.com/mueller-ma/PrepaidBalance/blob/992ea54c1be81ba1e3bf2843f6a41cff43b5e153/.github/workflows/build.yml#L21

So the current regex should be fine, correct?

[HonkingGoose]

OK but should it be "matchCurrentVersion": "/^3\\.", ? Note the ^ to enforce it at the start of the line, and the mandatory . (assumes that there will always be some precision to the version and not just `"3" itself, is that safe?)

Suggested change

	"matchCurrentVersion": "/3(\\.\\d+\\.\\d+)?/",
	"matchCurrentVersion": "/^3\\.",

This suggestion is the copy/pasted code from @rarkins. I don't know if it's a good idea to apply the suggestion...

I'll let the maintainers decide what to do with the code. 😉

[rarkins]

The current one allows 3, 30, 3d, etc. Is careful validation necessary to prevent these?

[github-actions]

Hi there,

This PR appears to have been inactive for a while. Please let us know if you are still working on it, or if we can close it for now.

Thanks, the Renovate team