Delay until certain "age" of release/commit/...

[ringods]

Does UpdateCLI have a feature to delay updating dependencies until the detected dependency has a certain age?

For example: I would like to delay taking in a new version of a dependency until it is at least 4 days old. Definitely for new major versions, this would allow to skip taking in this release possibly containing blocking bugs. Delaying would allow for a point release to become available by then.

Does this exist on certain resource types, or is this a condition I couldn't find in the docs?

[cookesan]

I do not see a built-in minimum-age option for the standard release/tag sources.

The relevant detail is that the version filters work on the candidate values themselves. For githubrelease, the source fetches releases, turns them into a list of tag names, then runs versionfilter.Search(...). The supported filter kinds are latest, semver, regex, regex/semver, time, regex/time, lex, and pep440; there is no minAge or olderThan field.

The time variants are different from what you want here. They parse date-like version strings, so they help if the version string contains a date, but they do not check the release's published_at.

For "only update when the selected release is at least 4 days old", I would implement it as an extra condition, usually shell or http, that queries the upstream metadata and fails until the selected version is old enough. That keeps the normal source choosing the candidate version, while the condition gates whether the target is allowed to change.

For GitHub releases the condition would need to call the GitHub REST endpoint for the selected tag/version and compare published_at with now minus 4 days. For container images or other registries, the same idea applies, but the metadata endpoint is provider-specific.

[olblak]

The concept of cooldown dependencies is not yet supported but it's pretty high on my need.

I have this issue #7866 to track the work needed.
I am almost done with supporting Golang ecosystem with this PR #8966
The next one which I plan to work on is about supporting github action which implies supporting git related plugins. (git branch, git tag, github release)