minimumReleaseAge resets the wait when a newer release is published

[Tanguille]

Raising this discussion after a discord conversation with @jamietanna.

Problem:
When an update has passed minimumReleaseAge and Renovate opens a PR for it, a subsequent release that hasn't yet passed MRA appears to update that same PR resetting the clock on the release that had already cleared the age gate, rather than leaving that PR alone and opening a separate PR for the newer release once it clears MRA.

Expected per @jamietanna:
"An update that has passed MRA will have a PR opened, but if a subsequent release is published, but hasn't passed MRA, it shouldn't update the existing PR until it's passed MRA" so this shouldn't be happening today.

What we had to disable to work around it:
We set rebaseWhen: "never" on our production package rules. Without it, a newer release that clears its own MRA window rewrites the still-open PR in place, so production would skip the exact version we'd actually validated on staging. The same resetting behavior described above, just via rebase instead of MRA. Turning that off serializes production onto "one open PR at a time, only advanced by merging it," which is a blunter tool than we'd like. It also blocks legitimate rebases we might otherwise want.

{
  description: "Production cluster updates with delay",
  matchPaths: ["kubernetes/production/**", "kubernetes/components/production/**"],
  minimumReleaseAge: "7 days",
  minimumReleaseAgeBehaviour: "timestamp-optional",
  // Serializes production into a queue of one. Without this, a newer release
  // that clears its own 7-day window rewrites an un-merged PR in place, so
  // production skips the exact version staging validated.
  // Merge the PR -> branch is deleted -> Renovate opens the next version.
  rebaseWhen: "never",
}

Suggestion:
Could there be a configuration option that causes subsequent releases to be opened in a new PR so the ones not merged yet are left alone and the MRA is unaffected? That seems like the ideal solution for this after analyzing this.

[jamietanna]

@Tanguille this might be better as a "Request Help" - we'd likely need an example of this happening before we can triage further

[Tanguille]

That makes sense, opened #45062 instead. If you need more data I can always provide 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