You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Support Dependency Cooldown for source plugin #7866
As explained very well here. We don't always want to use the very latest version of an application.
Solution you'd like
I would like to support the parameter cooldown for each source plugin where we can retrieve date information. This optional new parameter should be using "days" as a time measure.
A) Like Changelog: add it to the Resource interface, every plugin implements it (no-ops for those without timestamps). Consistent but touches all 30+ plugins.
B) Optional interface: source runner checks if the plugin supports cooldown, calls it if yes, warns if not. Smaller diff, less consistent.
Either way, cooldown would live at the source level (next to kind, name, transformers) rather than inside each plugin's spec, so it works uniformly without duplicating the field everywhere.
Thanks for the feedback, I was thinking about having cooldown parameters within versionfilter something like an interface there should be implemented by each source plugin that contains date informations
That makes a lot of sense — something like a Cooldown field on Filter with a SearchWithTimestamps(versions, timestamps) method that filters by age before delegating to Search(). Plugins with date data pass a map[string]time.Time, others just pass nil and it falls back to regular Search. Keeps it contained in versionFilter, no interface changes needed.
Activity
loispostula commentedon Mar 31, 2026
This is becoming a must-have in this ai enable world: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
loispostula commentedon Mar 31, 2026
I see two approaches:
A) Like Changelog: add it to the
Resourceinterface, every plugin implements it (no-ops for those without timestamps). Consistent but touches all 30+ plugins.B) Optional interface: source runner checks if the plugin supports cooldown, calls it if yes, warns if not. Smaller diff, less consistent.
Either way,
cooldownwould live at the source level (next tokind,name,transformers) rather than inside each plugin's spec, so it works uniformly without duplicating the field everywhere.olblak commentedon Mar 31, 2026
Thanks for the feedback, I was thinking about having cooldown parameters within versionfilter something like an interface there should be implemented by each source plugin that contains date informations
loispostula commentedon Mar 31, 2026
That makes a lot of sense — something like a
Cooldownfield onFilterwith aSearchWithTimestamps(versions, timestamps)method that filters by age before delegating to Search(). Plugins with date data pass amap[string]time.Time, others just pass nil and it falls back to regular Search. Keeps it contained inversionFilter, no interface changes needed.olblak commentedon Apr 1, 2026
Exactly that's what I had in mind
lemeurherveCB commentedon Apr 24, 2026
Adding https://cooldowns.dev/ FYI and/or inspiration
olblak commentedon Sep 21, 2026
I am removing this issue from the 1.0.0 milestone as it can be implemented later on