Only update package 'X' if there is also an update for package 'Y'

[JoostvdB94]

What would you like Renovate to be able to do?

I would like to specify rules for a group of dependencies in a way that an update would only be suggested if another package is also updated.

In the current situation it might be possible that the following scenario occurs:

• OpenSearch is updated (container / docker)
• The Helm template for the new OpenSearch is not yet available (helm)

When running Renovate, we I would like to be notified of a new OpenSearch update only when a new version of Helm (targetting that updated image) is also available.

The current grouping functionality makes a PR when at least 1 of the artifacts matching the criteria is updated. Could there also be a way to specify that there should only be a single PR when both OpenSearch and its Helm template are updated?

If you have any ideas on how this should be implemented, please tell us here.

Add a packageRule where a condition can be specified that checks other package upgrades (within the same group)

I have found something that might already be implemented, but the documentation about this is quite unclear:

• matchDepName
• matchDepPatterns

Which, by the name, might be used to specify dependencies for the group? Or am I mistaken?

Is this a feature you are interested in implementing yourself?

No

[viceice]

This isn't possible yet and the mentioned fields do work like the packageName fields.

[viceice]

I like that idea in general, but this seems to be very complicated to implement

[rarkins]

A way of solving this would be something like a generic "minimumUpdates" field for groups where the branch isn't created unless at least that number is met. Eg 2

[JoostvdB94]

@rarkins Thanks for your suggestion! That would fix 90% of the problems and indeed sounds much simpler.

However, it does not work so well for groups that are made based on patterns. In that case you cannot know the number of other updates.

Let's imagine the following scenario
We have applications A, B, C and D

Applications B, C and D all use resources exposed by application A.

You could specify the minimum number of updates to 2 and hope that when B changes, A changes too.
But when B and C update but A is unchanged, you would still get a PR suggesting an upgrade.

A more deterministic approach would be to specify package dependencies.
B depends on A
C depends on A
D depends on A

But if we can count the number of package updates in a group, we should also be able to see and check what packages are in that group, right?

[rarkins]

What percentage would you reach if you also combine with minimumReleaseAge setting? Eg wait a day or more before raising the PR. How often would A trail B,C,D?

[StefanLobbenmeierObjego]

For my use case, I would prefer a "compatability" settings to support this. This should be an enum of "MAJOR", "MINOR", "PATCH" and will indicate what version compatability is required across grouped packages.

Something like this:

• ✅ PR is created
• 🔴 No PR is created, wait for compatible versions

	Version A	Version B	MAJOR	MINOR	PATCH	default
Major version is different	2.5	3.4	🔴	🔴	🔴	✅
Minor version is different	2.5	2.7	✅	🔴	🔴	✅
Patch version is different	2.5.3	2.5.4	✅	✅	🔴	✅
Versions are exactly the same	2.5.3	2.5.3	✅	✅	✅	✅

As a first attempt, we could just look at the latest version, but ideally we check all versions and try to find the latest compatible versions.

[StefanLobbenmeierObjego]

my usecase in more detail:
ironpdf java client library udpates once a month, requires the latest version of the docker container at the time of release, usually minor version is the same

ironpdf docker container updates 20 times a month, I am not interested in most of those updates since they are not compatible with the java client library