Add matchReleaseAge matcher

[mzglinski]

Proposal

I propose adding a matchReleaseAge matcher, similar in functionality to matchCurrentAge. This matcher would align closely with minimumReleaseAge but serve a different purpose.

I previously submitted a PR for this feature, which I can rebase and reopen if this proposal is approved: #30359.

Why?

This feature is aimed at reducing unnecessary noise and resource usage. In my organization, it's required that all PRs remain up-to-date with the default branch. However, if a PR is left unattended by the repository owner, it gets continuously updated every time changes are pushed to the default branch. This results in constant notifications and excessive consumption of CI resources. The proposed rule would allow us to bundle "forgotten" dependencies into a single PR, which can be addressed at the owner's convenience.

Simultaneously, I want Renovate to create a dedicated PR for new releases of older packages, giving developers the option to update a single package if needed.

Here’s the logic I want to implement:

1. Create a dedicated PR if a new release is at least 3 days old (as governed by minimumReleaseAge) but younger than 14 days.
2. If a package is not merged within this timeframe, include it in the "outdated dependencies" group PR.
3. When a new version of an older package is released, repeat step 1.

Why not use minimumReleaseAge?

In my original PR it was suggested to use minimumReleaseAge as follows:

{
    "matchCurrentAge": "> 1 month",
    "minimumReleaseAge": "14 days",
    "matchUpdateTypes": ["major", "minor", "patch", "digest"],
    "groupName": "outdated dependencies"
}

While minimumReleaseAge nearly meets my requirements, it doesn’t create new, separate PRs when a new version of an older package is released. Instead, Renovate waits 14 days before creating a PR in the "outdated dependencies" group. This behavior doesn’t fully align with the intended functionality of creating timely, individual PRs for newly released versions.

[rarkins]

Can you give some examples of realistic new packageRules you'd use it with?

[mzglinski]

Of course, modifying the above example to achieve my desired outcome, would look like this

{
  "extends": ["config:base", "github>whitesource/merge-confidence:beta"],
  "branchConcurrentLimit": 5,
  // wait for 3 days before creating any pr
  "minimumReleaseAge": "3 days",
  "packageRules": [
    // group older packages into single MR
    {
      "matchCurrentAge": "> 1 month",
      "matchReleaseAge ": "> 14 days",
      "matchUpdateTypes": ["major", "minor", "patch", "digest"],
      "groupName": "outdated dependencies"
    },
  ],
  "platformAutomerge": true,
  "prConcurrentLimit": 3,
  "prHourlyLimit": 1,
  "rebaseWhen": "behind-base-branch"
}

With this configuration renovate will

1. Create a new PR (let's call it A) for package (P) new release (R) if the release age is at least 3 days old
2. If the A is not merged within 14 days, and the current release age is over a month, then A will be closed, and R will be added to the outdated dependencies PR.
3. If P receives a newer release, start from step 1.

With this approach, I will be able to reduce the number of "forgotten" PR's, free CI resources and allow other packages to be updated in the meantime (notice prConcurrentLimit, it is not uncommon in my organization this setting to create a deadlock if all 3 PR's are failing).

[rarkins]

One other undesirable thing: in your situation, dependencies which release e.g. weekly will never make it into the old group, even if developers haven't updated it in years. There's also a different case where an old update is in the PR because it's e.g. 2 months old but then a newer release comes out and it goes back to its own PR again. You could see quite a lot of flip-flopping. And actually in either of these cases you might see the update disappear from the grouped PR but not be created separately again yet because your concurrency limit is met. Then wait another couple of weeks and it appears again, potentially without ever being able to be created on its own.

So I understand your motivations and how this helps, but I also think there's a lot of scenarios where it doesn't help at all, and some where it will be outright confusing, if not unhelpful. These problems don't occur for matchCurrentAge - they will be new problems introduced by this feature.

[mzglinski]

I understand your concerns, but this feature provides more flexibility to the user. For instance, if I identify that certain packages are released weekly, I can exclude them from the rule or create a specific rule for those packages. This level of control isn't possible with minimumReleaseAge, as it is an attribute, not a matcher.

Additionally, separateMajorMinor is enabled by default, which divides the group into "outdated dependencies" and "outdated dependencies (major)." In my experience (using this setup with minimumReleaseAge), it offers a smoother experience for developers.

I agree this isn't a one-size-fits-all solution, but it is a step in the right direction that can provide significant benefits.

Another example of its usefulness would be assigning labels based on release age, and I'm sure we could discover other applications as well.

Perhaps extending the documentation to address the concerns you've raised would help ensure users fully understand how this matcher works?

[rarkins]

Another example of its usefulness would be assigning labels based on release age, and I'm sure we could discover other applications as well.

This is actually another example of how confusing it could get: labels are a branch/PR concept, while release age is per-upgrade. You would need to add even more logic if for example you want the branch label to reflect the oldest release in the branch.

I think I can accept this if we flag this as experimental so that it can be removed in future if the problems or confusion it causes are worse than the benefits. If it turns out to be fine and not cause a support or maintenance burden then we can keep it.

[mzglinski]

Ok, I can mark it as experimental, no problem. What are the next steps now? Should I make the changes, reopen the PR, and link this discussion to it? Is that enough, or do some other steps have to be taken?

[rarkins]

Yes, please go ahead with that