Package agnostic security:minimumReleaseAge preset

[NVolcz]

Tell us more.

There is currently the security:minimumReleaseAgeNpm that is specific to NPM. With the support for release age for other registries, it would be useful to provide a single preset to set a release for all package managers. I would like to better understand if the other registries would benefit from having similar exceptions like the NPM preset. Do anyone know?

[jamietanna]

I think, yes it would be useful to have

Although we don't have any Issues to track it, this is something we are definitely interested in doing

The reason we've not yet worked on this is two part - time and time 🤓

Kidding aside, there's a fair bit of work we'd put into enablement of the feature for the npm datasource - a lot of that is done now (either general hardening of the feature, or working out how best to work with the managers), but we'd still want to make sure that we'd considered some similar cases for different datasources/managers i.e. lockFileMaintenance not being goverened by it

To be extra clear to anyone reading - this isn't an "on by default" preset we're talking about, but a handy way of turning this on for a specific datasource

We could use a templated preset to parameterise the "number of days" to wait, if that would be useful

[jamietanna]

Which Managers/Datasources would you be thinking of this being for? Are you currently using minimumReleaseAge for all/a subset of packages?

[NVolcz]

We were previously using:

{ "matchDatasources": ["npm"], "minimumReleaseAge": "7 days" }

but will now test using something like:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "minimumReleaseAge": "7 days",
  "minimumReleaseAgeBehaviour": "timestamp-optional",
  "packageRules": [
    {
      "description": "Do not require Minimum Release Age for update types that are controlled by the package manager",
      "matchUpdateTypes": ["lockFileMaintenance"],
      "prBodyNotes": [
        "⚠️ Renovate's lock file maintenance functionality does not support validating Minimum Release Age, as the package manager performs the required changes to update package(s). Confirm whether your package manager perform its own validation for the Minimum Release Age of packages."
      ],
      "minimumReleaseAge": null
    },
    {
      "description": "Do not require Minimum Release Age for package replacements",
      "matchUpdateTypes": ["replacement"],
      "prBodyNotes": [
        "⚠️ Renovate's replacement functionality [does not currently](https://github.com/renovatebot/renovate/issues/39400) wire in the release age for a package, so the Minimum Release Age checks can apply. You will need to manually validate the Minimum Release Age for these package(s)."
      ],
      "minimumReleaseAge": null
    },
    {
      "description": "Do not require Minimum Release Age for package pinning",
      "matchUpdateTypes": ["pin"],
      "prBodyNotes": [
        "⚠️ Renovate's pin functionality [does not currently](https://github.com/renovatebot/renovate/issues/40288) wire in the release age for a package, so the Minimum Release Age checks can apply. You will need to manually validate the Minimum Release Age for these package(s)."
      ],
      "minimumReleaseAge": null
    }
  ]
}

[jamietanna]

Via

Given your config 👆🏽, you're setting minimumReleaseAgeBehaviour=timestamp-optional which means that every manager (regardless of whether they support releaseTimestamps or not) will allow a dependency update if they don't have a releaseTimestamp.

For instance, Renovate's npm manager (for npm, yarn, or pnpm), which is largely used with registries that do have releaseTimestamps will result in you starting to receive updates for packages that don't have a releaseTimestamp.

If you're only using registries that support releaseTimestamps, then you're OK - but if you happen to have any registries or packages that don't have one, you'll now receive an update as soon as Renovate sees it.

I'd personally recommend making it a stricter allowlist with packageRules - only set it on managers and registries you're happy receiving updates for, and making that explicit can make it clearer what the behaviour will be.