The best way to do this is with packageRules, with a combination of matchManagers, matchDatasources, matchPackageNames and matchPackagePatternsĮxamples of versioning overrides Overriding Docker versioning to use a versioning specific for a package.More commonly you would need to configure versioning for individual packages or potentially package patterns.Although you can reconfigure versioning per-manager or per-datasource, it's unlikely that such a broad change would ever be needed.General concepts behind overriding versioning You generally won't need to override the defaults for ecosystems which enforce a strict version scheme like npm.Ĭonfiguring or overriding the default versioning can be particularly helpful for ecosystems like Docker/Kubernetes/Helm, where versioning is barely a 'convention'. You can manually configure/override the versioning value for a particular dependency. It's impossible to automatically detect all versioning schemes, so sometimes you need to tell the bot what versioning scheme it should use. Renovate interprets versions correctly out-of-the-box most of the time. Why you might need to manually configure versioning The 'versioning' is different for each package manager, because different package managers use different versioning schemes.įor example, npm uses 1.0.0-beta.1 and pip uses 1.0.0b1. Once Managers have extracted dependencies, and Datasources have located available versions, then Renovate will use a 'Versioning' scheme to perform sorting and filtering of results. Should you Pin your Javascript Dependencies? Overriding Docker versioning to use a versioning specific for a package

Terraform version constraint