transformDatasourceVersion

[rarkins]

Describe the proposed change(s).

Tell us more.

Related discussions:

• different versioning schemes in datasource and local git #23276
• Unable to make Renovate to report new GitHub release assets #31249
• Regex Manager for Minio #34551

There are times when a datasource's version string is similar but different to the string in the repo (currentValue). For example 1.2.3 versus 1-2-3. We could use a versioning like regex to extract major/minor/patch from both of these, but if 1-2-4 were available then the string 1.2.3 in the repo would be replaced with 1-2-4 instead of 1.2.4.

We should rename and enhance extractVersion to also allow transformation:

• New option name is transformDatasourceVersion
• It's an array of strings, with length 1 or 2
• If length 1, it must contain a version capture group
• If length 2, the second element is the "transform" part
• We migrate any existing extractVersion string to be an array of length 1 for transformDatasourceVersion

As an example, let's say the currentValue is minio_20250218162555.0.0_amd64.deb while an equivalent raw datasource version is RELEASE.2025-02-18T16-25-55Z. In this case it's intended that transformDatasourceVersion could be ["^RELEASE\.(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})T(?<hour>\d{2})-(?<minute>\d{2})-(?<seconds>\d{2})Z$", "minio_{{year}}{{month}}{{day}}{{hour}}{{minute}}{{seconds}}.0.0_amd64.deb"].

[viceice]

wouldn't a string or object type easier for validation and json schema 🤔

[rarkins]

I was trying to avoid a complex config structure, especially for the most common use case of extractVersion on its own. Would you prefer keeping extractVersion as-is and passing its results (groups) to a new transformVersion?

[viceice]

I was trying to avoid a complex config structure, especially for the most common use case of extractVersion on its own. Would you prefer keeping extractVersion as-is and passing its results (groups) to a new transformVersion?

yes

[rarkins]

I have doubts that it's good design either. It introduces two problems:

• You could write an extractVersion which is intended to be used with transformVersion, but no transformVersion exists
• You could write a transformVersion with a missing extractVersion

Also in both cases you could have a mismatch of groups in transformVersion vs extractVersion, but it's much easier to validate when they're in the same config option versus separate.

Good design would be one where it's hard to get it wrong like that

[mvgadagi]

Hello Rhys,

I am happy to contribute on the implementation of this change, but I would like to quickly review the approach first once based on your proposal..
I would like to keep extractVersion rather new config transformVersion (just to keep this in line with extractVersionTemplate naming we have on other config, so I am sticking with 1st option you highlighted ), and the implementation on a high level looks as below, If it's fine I will get some draft changes ready probably in a week on this..

1. Change extractVersion format: Convert extractVersion from a string format to an array format.
2. Update extractVersion types: Allow extractVersion to support types string [string], or [string, string]. In future releases, we can phase out the string type and retain only [string] and [string, string] types.
3. Support configMigration: Ensure that the current extractVersion (in string format) is migrated to the array format, keeping the extraction pattern in the 0th index.
4. Support for transformation: In case transformations are needed, we can leverage the 1st index as below

    {
      "packageRules": [
        {
          "matchPackageNames": ["my-package"],
          "extractVersion": [
            "^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)(?:-(?<prerelease>.*))?$",
            "{{major}}-{{minor}}-{{patch}}{{#if prerelease}}-{{prerelease}}{{/if}}"
          ]
        }
      ]
    }

for example, this approach will transform versions like 1.2.3 into 1-2-3, and for pre-release versions, 1.2.3-beta.1 will be transformed to 1-2-3-beta.1.
6. Update internal usages of extractVersion in presets: all internal components relying on extractVersion are updated to use the array format, with the extraction pattern in the 0th index.
7. Finally update the docs changes

Thanks a lot in advance !!

[mvgadagi]

Hello guys,
Could you please have a look at this approach quickly once.
Thanks a lot !!

[rarkins]

Sorry for the delay - yes that looks good. Some comments:

• There's no urgency to phase out string -> array massaging. We generally maintain our migrations "forever"
• Ideally we could have a reliable way to determine that all variables used in [1] are extracted by [0] (i.e. so that we can proactively warn about invalid config). We may not be able to catch every possible way a variable is used in handlebars, but the simple ones like in your example could be checked for

[mvgadagi]

Thanks a lot Rhys for your feedback.
Will contribute on this change and propose a draft PR in coming weeks ..

[rarkins]

Converted to a discussion, as the Issue is disputed

[tijmenvandenbrink]

For the time being I'm using the following:

    {
      "description": "MinIO server uses custom RELEASE timestamp versioning",
      "matchDepNames": ["quay.io/minio/minio"],
      "versioning": "regex:^RELEASE\\.(?<major>\\d{4})-(?<minor>\\d{2})-(?<patch>\\d{2})T(?<build>\\d{2}-\\d{2}-\\d{2})Z?$",
      "labels": ["minio", "timestamp-versioning"]
    },

Not the cleanest approach but it seems to work for what I want it to do.

[h0nIg]

there is a second reason that transformation is required. regex versioning fails with takt based versions, which contains letter being mandatory part of the version: rel-2026.T02a.1772881384

02a is a different minor version than 02b

[jamietanna]

@h0nIg please don't mention maintainers - we subscribe to threads (and @rarkins is no longer a maintainer)