Needs a renovate pattern for accepting such migration path :both v2.1.0-20260514 → v2.2.1 but ignores v5.3.0-20260514 → v5.3.0

[cridam]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

43.256.0

Please tell us more about your question or problem

when using docker versioning , v2.1.0-20260514 → v2.2.1 is never suggested, the v2.1.0-20260514 is ignored
when using loose versioning, v2.1.0-20260514 → v2.2.1 is suggested but v5.3.0-20260514 → v5.3.0 is not desired.
Is there a way to configure to only accept migration towards a patch +1 or towars a patch-xxxx .
I put som exception rules (-dev, -rc ...) with loose versionning, my concern is how to define a rule to authorize the expectation below.

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[0xshubhs]

Both symptoms are the same cause.

docker versioning reads -20260514 as a compatibility value, and per the regex versioning docs:

compatibility: this value defines the "build compatibility" of a given dependency. A proposed Renovate update will never change the specified compatibility value.

v2.2.1 has no suffix so it's a different bucket, never offered. Nothing to do with the numbers.

loose has no compatibility concept at all, so dropping the suffix looks valid to it.

You want the date as a fourth numeric part instead of a tag. That's build:

{
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["<your image>"],
      "versioning": "regex:^v(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)(-(?<build>\\d+))?$"
    }
  ]
}

Your two cases:

v2.1.0-20260514 is 2.1.0 build 20260514, v2.2.1 is 2.2.1 build 0. Minor and patch go up, so it's an update. Offered.

v5.3.0-20260514 is 5.3.0 build 20260514, v5.3.0 is 5.3.0 build 0. Same version, lower build, so it's a downgrade. Not offered.

You can drop the -dev/-rc exceptions you added under loose, the ordering handles it.

Two gotchas: capture groups have to be purely numeric, which is why v sits outside the group. And build updates rank as patch updates, so they'll land in your patch PR stream.

[jessadakronp]

Use regex versioning and capture the date as build — not as a prerelease and not as a compatibility suffix:

{
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["your/image"],
      "versioning": "regex:^v(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)(?:-(?<build>\\d+))?$"
    }
  ]
}

The capture group is what decides the behaviour. build gets appended as a fourth element of the release array, and missing parts compare as 0, so v5.3.0-20260514 is [5,3,0,20260514] while plain v5.3.0 is [5,3,0,0] — the plain tag sorts lower, so that update is never proposed. v2.1.0-20260514 is [2,1,0,20260514] against [2,2,1] for v2.2.1, which is higher on minor, so that one is proposed. Dated to newer dated (v2.1.0-20260601) keeps working as well.

The other two groups give you exactly the two behaviours you are trying to get away from: prerelease follows semver, where v5.3.0-20260514 < v5.3.0, so the unwanted update comes back; compatibility is essentially what docker versioning does with the suffix — it never updates across different suffixes, which is why v2.1.0-20260514 -> v2.2.1 was never offered.

Useful side effect: the regex acts as an allow list, so -rc / -dev and similar tags don't parse at all and are skipped. That should let you drop the exception rules you added under loose versioning.

Checked against renovate 43.288.0:

isGreaterThan("v2.2.1", "v2.1.0-20260514")           true
isGreaterThan("v5.3.0", "v5.3.0-20260514")           false
isGreaterThan("v2.1.0-20260601", "v2.1.0-20260514")  true
isValid("v5.3.0-rc1")                                false

Adjust the v prefix and the separator to your real tags — anything the regex doesn't match is invisible to Renovate.