minimumReleaseAge-passed PRs get rewritten in place once a newer release also clears MRA

[Tanguille]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

43.259.2

Please tell us more about your question or problem

Follow-up to #45037, moved here per @jamietanna's suggestion.

Summary:
minimumReleaseAge itself works correctly. A release is only ever selected once it has genuinely cleared its own age window. The gap is that Renovate has no concept of a PR being pinned to the specific release that first graduated; once a later release also clears MRA, the existing branch gets rewritten onto it, discarding the fact that an earlier, already-qualified release was sitting there mergeable.

Where this happens (traced in source, not just observed):

• filterInternalChecks() in lib/workers/repository/process/lookup/filter-checks.ts: on every run, for a given (dependency, update-bucket), it picks the newest release that currently passes minimumReleaseAge. Correct in isolation.
• lib/workers/repository/update/branch/index.ts:567-578: the only thing stopping that newly-selected candidate from overwriting an existing open branch is rebaseWhen: "never". Without it (the default), the branch converges to whatever the latest run picked.

So in practice: PR opens for v1 once v1 clears MRA. Later, v2 is published and also clears its own MRA window on a subsequent run. The same PR gets rewritten from v1 to v2 in place, rather than v1's PR staying untouched and a separate PR opening for v2.

Our config, for reference:

{
  description: "Production cluster updates with delay",
  matchPaths: ["kubernetes/production/**", "kubernetes/components/production/**"],
  minimumReleaseAge: "7 days",
  minimumReleaseAgeBehaviour: "timestamp-optional",
  rebaseWhen: "never",
}

Workaround today:
rebaseWhen: "never", which serializes updates into a queue-of-one — stops the rewrite, but also blocks legitimate rebases we'd otherwise want (conflict resolution, etc.).

Ask:
Is there an option to add a mode where each release that clears minimumReleaseAge gets (or keeps) its own PR, instead of the update-bucket always converging onto a single branch tracking the latest passing candidate? Or am I just doing something wrong?
If a proper feature request/Issue is a better fit than a Discussion for this, happy to move it there.

Logs (if relevant)

Unfortunately I couldn't find the logs back since I've been using a workaround for longer then the logs have been saved. If it is genuinely useful for this feature request / ask I will reproduce it.

[github-actions[bot]]

Hi there,

Please help this Discussion progress by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the reproduction in your own repository. Ensure it's actually minimal (no unnecesary dependencies or config), or it will be rejected by maintainers.
5. Install the Renovate app to verify that what you say happens (or doesn't happen) reproduces.
6. Fill out the information in your repository's README.md. What you describe there should reflect what you see in this repo, with the hosted app, and not what you saw in your original repo/environment.
7. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.
8. Add a Discussion comment mentioning that the reproduction repo is now available and linked.

If you need help with running Renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team

[jamietanna]

We'll need a repro to go any further from here

[Tanguille]

Okay I'll try to set this up but since this is time consuming I can't promise a timeline.

Given the mechanism is timing-dependent (a release needs to clear MRA, then a later release needs to also clear MRA on a subsequent run, without the first being merged), I'll build it against a real npm package with genuine registry timestamps so the before/after is deterministic rather than needing to fabricate timestamps. Will link it here once it's up and I've confirmed the behavior actually reproduces on the hosted app.

[jamietanna]

And in that case, why do you not want Renovate to update that existing PR? As far as I can tell, minimumReleaseAge has passed in that case, so it's a similar behaviour to when an open PR is updated because it's not been merged

[Tanguille]

Because then the version that passed MRA will never able to get merged since a new MRA period has started before I get the chance to merge it.

So with packages that frequently update an MRA of 7 days causes them to never get updated which goes against the reason I'm using renovate in the first place.

I think having a seperate branch per update as a configuration option also isn't wrong semantically in any way and seems like the cleanest solution for this case to me.

[jamietanna]

So in practice: PR opens for v1 once v1 clears MRA. Later, v2 is published and also clears its own MRA window on a subsequent run. The same PR gets rewritten from v1 to v2 in place, rather than v1's PR staying untouched and a separate PR opening for v2.

Are you only seeing this for major versions, or across different version types? Trying to work out the functionality you're wanting,t oo

[Tanguille]

Across version types. Our concrete example was actually a patch bump, not a major: ghcr.io/siderolabs/installer went v1.13.4 → v1.13.5 (PR opened once v1.13.5 cleared our 7-day MRA), then got rewritten in place to v1.13.4 → v1.13.6 three days after v1.13.6 released.

Nothing in filterInternalChecks() treats major/minor/patch differently for this, it just picks the newest release in the candidate list that currently passes minimumReleaseAge for whatever update-bucket it's evaluating, then rebaseWhen decides whether that gets pushed onto an existing branch. So the behavior should reproduce for any update type where two releases land close enough together that the first clears MRA before the second does. Patch is actually the easiest case to trigger it in practice, since patch releases tend to ship more frequently than majors.