Improve minimumReleaseAge documentation and link to from renovate/stability-days builds

[setchy]

What would you like Renovate to be able to do?

Create a dedicated documentation page to explain how Stability Days works.

Then use this new page as the hyperlink for the renovate/stability-days build, like those below

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

create new docs page and update builds to reference it

Is this a feature you are interested in implementing yourself?

Maybe

[setchy]

Based off this discussion: #21008

[setchy]

And this, more thoroughly documented discussion - #14948

[HonkingGoose]

create new docs page and update builds to reference it

We already have some stabilityDays config option docs ¹. We could:

• Trim the config option docs for stabilityDays so it only shows "basic configuration"
• Create new "Key concepts, stability days" page
• Move the full explanation to the new page

Footnotes

1. stabilityDays config option docs ↩

[rarkins]

Also keep in mind we would like to rename stabilityDays: #12914

So ideally don't name the file like "stability-days.md" so that its content can change later if necessary

[HonkingGoose]

Also keep in mind we would like to rename stabilityDays: #12914

Thanks for reminding me! 😄

So ideally don't name the file like "stability-days.md" so that its content can change later if necessary

I read issue #12914 and I think you still need to decide on the new name for the overall concept of stabilityDays or minimumReleaseAge? I'm happy to start using the new name, once we decide what that name is. 😄

[setchy]

I like the sound of minimumReleaseAge... Matches up OK with the merge confidence badges

[HonkingGoose]

What we have now:

• stabilityDays is now called minimumReleaseAge
• Renovate docs for minimumReleaseAge

The original request of this issue was to:

Create a dedicated documentation page to explain how Stability Days works.

Do we still want/need a separate page?

The minimumReleaseAge config option docs explain:

• That it was renamed from stabilityDays
• Which conditions need to be met for Renovate to check the set duration
• That Renovate waits for the set duration to pass for each separate version
• That you can use selective-scheduling, and links to the docs for that concept
• That Renovate adds a pending status check, and replaces it with a passing check when the minimumReleaseAge is met
• That some datasources don't have a release timestamp, which means the feature does not work. Or that Renovate does not support a release timestamp for a datasource yet
• Note for Maven users when Maven source has unreliable last-modified headers
• Note admonition that configuring this option means you get a new status check: renovate/stability-days

And it covers some uses:

• Suppress branch/PR creation for X days
• Prevent holding broken npm packages
• Await X time duration before Automerging

Discussion

It seems like we have a good starting point with the current minimumReleaseAge config option docs. @setchy can you take a look at what we have now, and explain what you think is missing?

[setchy]

@HonkingGoose well summarized, great to see the progress on this.

I had a quick look at my use-cases and noticed two items

1. Bitbucket Pipeline build (for branch status) is linked to https://docs.renovatebot.com/, not https://docs.renovatebot.com/configuration-options/#minimumreleaseage. This is true for all platforms. Raised feat(branch-status): use targeted doc links for merge confidence and minimum release age #28378 to address

2. branch name defaults to renovate/stability-days - but looks to be configurable via https://docs.renovatebot.com/configuration-options/#statuschecknames

[HonkingGoose]

2. branch name defaults to renovate/stability-days - but looks to be configurable via https://docs.renovatebot.com/configuration-options/#statuschecknames

We have an issue to rename the status check, that seems related?

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

The rename issue is blocked by this one:

• Major release backwards compatibility for hosted users #19980