Support updating version-specific info inside compatibility suffixes

[wrslatz]

What would you like Renovate to be able to do?

Renovate should be able to analyze version-specific info (major, minor, patch) within the compatibility section of the version of a dependency.

In Docker tags, it is common for the compatibility part of the tag to include version info (i.e. -alpine3.14). Without this capability, Dockerfile tags that include version info in the compatibility section, where that same compatibility tag no longer exists in newer versions (e.x. img1.2-alpine3.14 to img1.3-alpine3.15, where img1.3-alpine3.14 never exists), will never see version updates proposed by Renovate.

Practical example: Node.js images (see current tags here). It would be great to get proposed updates from any of 17-alpine3.14, 17.3-alpine3.14, 17.3.1-alpine3.14 to 17-alpine3.15, 17.3-alpine3.15, 17.3.1-alpine3.15 respectively. You could use -alpine tags alone, but you lose precision into the underlying Alpine version and increase the risk of consuming breaking changes without knowing.

See the Docker Version compatibility docs for more info on how this works today. Regex versioning is also related.

I split this out as a separate request from #5990 (comment) to be discussed on its own. I'm not sure if this is more relevant to managers or to versioning support (probably the latter?).

If you have any ideas on how this should be implemented, please tell us here.

Introduce a concept of compatibilityVersioning, where the compatibility section of the version is parsed for version info. The matching logic could be similar to the general regex matching logic but applied within the compatibility section, so something like ^(?<compatibility>.[A-Za-z] )(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)?$.

This would complicate how Renovate looks for updated dependency versions, increasing the number of tags it would need to check. Example: Renovate would need to check combinations of 1) same version info except compatibility version update 2) update to version info except same compatibility version, and 3) both update to version info and compatibility version.

It may also be difficult to parse version info out of compatibility (there may be examples where numeric characters are used as part of the compatibility tag and do not represent version info). Consumers may also want to separate regular version updates from compatibility version updates when applicable, adding additional config and support requirements (similar to separateMinorPatch).

Perhaps a preferred order could be considered here to make the proposed updates more deterministic. Ex: Renovate could look for updates to both version and compatibility, version alone, and then compatibility alone.

Some alternatives or workarounds that may be suitable

1. Use a tag with less-specific compatibility (i.e. -alpine over -alpine3.14) in combination with digest pinning. This would help prevent consuming breaking changes from compatibility updates in the less specific tag. It still reduces visibility into the underlying Alpine version being used.
2. Use replacements to manually replace specific instances where the specific compatibility version info will no longer receive updates. This would depend on Docker support in replacements being completed in Replacing deprecated dependencies for docker datasource only replace version #12623 first. It's also a manual process for each image, making it less than ideal and a large burden to maintain for many images.

Is this a feature you are interested in implementing yourself?

Maybe