Improved age filtering/controls

[rarkins]

What would you like Renovate to be able to do?

Be able to control not only the release's minimum age (minimumReleaseAge) but also the potential to control all of these separately or at once:

• release age
• minor age
• major age

The idea is you can e.g. control through config: "Don't raise a major PR until it's at least a month old, and no new release for 3 days"

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

Maybe add minimumMinorStreamAge and minimumMajorAge.

For a release like 2.3.4:

• minimumReleaseAge would be how old 2.3.4 is
• minimumMinorStreamAge be how long since 2.3.0 was released
• minimumMajorAge would be how long since 2.0.0 was released

We probably need to allow a more flexible syntax than days too. Maybe even invent our own like 1m2w3d4h

Is this a feature you are interested in implementing yourself?

No

[HonkingGoose]

Do you want to rename stabilityDays -> minimumReleaseAge in a new breaking release soon then? We're already gearing up for more breaking changes right now. I think the new name is way better! 😄

[rarkins]

We don't need to do a breaking release as long as we add migration code, which in this case should be fairly easy.

[HonkingGoose]

Do you want a new issue to track the rename of stabilityDays -> minimumReleaseAge?

[rarkins]

Let's keep it here for now, we can maybe break it out later if we implement it separately. We will want to use a new unified syntax for all.

BTW minimumMinorAge is shorter but I worried it might "sound wrong". What do you think?

[secustor]

Wouldn't it be more intuitive from the UX perspective to use the major, minor configuration blocks instead of minimumMinoror minimumMajor?

[rarkins]

No, because then they'd get merged over the top and you could have only one. Also, you wouldn't know if it applies to 2.3.4, 2.3.0 or 2.0.0.

[HonkingGoose]

@rarkins I think you have decided on a better name, but forgot to mention it in this issue?

Relevant part of something you said elsewhere ¹:

... new majorStreamDelay feature (sorry, forget which name I proposed) inside Renovate ...

Footnotes

1. https://github.com/renovatebot/.github/pull/32#issuecomment-994720312 ↩

[rarkins]

I'm not sure it's better :)

[HonkingGoose]

Oh I see! I misunderstood your comment... 🙈

I thought it was meant in a "I've found a better name" way, but it's really more like: "I know there's a feature request out there somewhere with this sort of feature, what's the name again?" way... 😄

It's tricky to find a better name that works for major, minor and patch level updates delays.

[mcmxcdev]

Cool to find this issue; more flexibility for stabilityDays would definitely be appreciated!

In our team, we are currently debating a missing functionality that would be helpful for us in regards to stabilityDays:
Delay a minor release e.g. by 30 days with stabilityDays, but then don't pick the version based on timestamp or release date but pick the latest patch version on the same minor version range, which would be bug fixes for that minor release potentially.

This came up due to us receiving a PR to upgrade pnpm which is releasing quickly in small increments.
Renovate would upgrade us from 7.13.0 to 7.13.2 right now, but we would like to consume 7.13.6 ideally. We know there is no guarantee that this version will be bug free, but it might be better than previous ones.

Would be great to have this considered.

[HonkingGoose]

This came up due to us receiving a PR to upgrade pnpm which is releasing quickly in small increments.
Renovate would upgrade us from 7.13.0 to 7.13.2 right now, but we would like to consume 7.13.6 ideally. We know there is no guarantee that this version will be bug free, but it might be better than previous ones.

@mcmxcdev You can get close to your ideal workflow by:

• Setting the pnpm package to a monthly schedule
• Enabling the Dependency Dashboard
• To update pnpm earlier: request the pnpm update on the Dependency Dashboard

I recommend "pinning" the Dependency Dashboard issue on your repository. ¹ That way your team will always see it. 😉

Renovate config:

{
  "extends": [":dependencyDashboard"],
  "packageRules": [
    {
      "matchPackageNames": ["pnpm"],
      "extends": ["schedule:monthly"]
    }
  ]
}

Links to Renovate documentation:

• :dependencyDashboard preset
• schedule:monthly preset
• matchPackageNames
• Dependency Dashboard key concept page

Footnotes

1. GitHub Docs, pinning an issue to your repository ↩

[mcmxcdev]

Hey @HonkingGoose, thanks for the detailed response!
I think you might have misunderstood: we have set schedule to weekly, dependency dashboard is already enabled, but we want to delay existing updates by 30 days intentionally and then fetch the latest patch version of a minor.

WIth your suggestion, we would wait a month but then get the newest versions which are most likely not battle-tested yet.

[rarkins]

How can you say "delay by 30 days" but also "latest patch version"? e.g. what if the latest patch version is 2 hours old? Can you explain in more detail what you're after with examples?

[HonkingGoose]

I remember that @rarkins worked on merge confidence badges a while back. Renovate may be extended so that you can select what "confidence level" you want for updates. I think we only show the badges, with no way to use the merge confidence data in a packageRule?

https://github.com/whitesource/merge-confidence

[HonkingGoose]

Related issue:

• Rename renovate/stability-days status check to renovate/minimum-release-age #21442