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