^{Originally posted by mthalman December 10, 2024}

Tell us more.

The versionCompatibility setting only works for version patterns that consist of a single compatibility group. But there can be cases where multiple compatibility groups are needed. This is discussed in #33016.

I'll illustrate this with an example of Docker tags.

This is a source file with a reference to a Docker tag:

FROM mcr.microsoft.com/dotnet-buildtools/prereqs:debian-11-helix-amd64

The dotnet-buildtools/prereqs repo contains images from multiple Linux distros. So the tagging pattern is <distro>-<version>[-<variant>]-<architecture>.

Here's a sample of the tags in the repo:

[
  "debian-11-helix-amd64",
  "debian-12-helix-arm64v8"
]

Using the config below, it will cause Renovate to open a PR to update the source file to reference the debian-12-helix-amd64 tag, which doesn't exist:

{
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["mcr.microsoft.com/dotnet-buildtools/prereqs"],
      "versionCompatibility": "^(?<compatibility>\\D+)-(?<version>\\d+(\\.\\d+)?).*$",
      "versioning": "docker"
    }
  ]
}

The issue is that the version number in the tag is contained in between the two sections that identify compatibility. What is needed is a way to define a versionCompatibility pattern that defines multiple compatibility sections.

It is proposed to add compatibilityPrefix and compatibilitySuffix in addition to the existing compatibility. Any combination of these should be allowed.

Here's an example of how this could be defined:

"versionCompatibility": "^(?<compatibilityPrefix>\\D+)-(?<version>\\d+(\\.\\d+)?)(?<compatibilitySuffix>.*)$",