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