Repository navigation
Feature Request: Rename "latest" in versionfilter to something not overloaded by GitHub et al, i.e. "most_recent" or "youngest" #9864
Description
Is your feature request related to a problem?
The versionfilter in the github_release source uses "latest" to mean the "most recent release sorted by release date".
Unfortunately, latest is used by GitHub to mean something different along the lines of "the stable release that the project considers to be the most recent usefule one" or similar.
This causes confusion IMHO.
Solution you'd like
I would like to propose latest being deprecated in favor of youngest or most_recent or similar in the versionfilter.
And only keep latest in the typefilter which can get the release flagged by Github as latest.
Alternatives you've considered
The documentation explains the difference, but it is not obvious that there might be a mismatch. I.e. new users might not know that they misunderstand latest here.
Anything else?
Kind Regards,
Johannes
Activity
olblak commentedon Aug 7, 2026
I totally understand the confusion but here we have two different challenges
One is a technical limitation, versionfilter is a generic piece of code reuse by most of the plugin cfr so it needs to stay generic enough otherwise we'll endup with a lot of duplicated code for each plugin.
That's why for example the githubrelease plugin has the "typefilter" parameter or the docker plugin has the setting
tagfilterto have specific plugin filteringThe second one as you noticed is the meaning of "latest" which can differ between enduser and the api we interact with.
For example retrieving the latest docker image tag for
ghcr.io/updatecli/updatecliandupdatecli/updatecliwould return different value because by ghcr.io and dockerhub don't return the value sorted in the same way.On github release it's gonna be the newest release by date.
kastl-ars commentedon Aug 7, 2026
I understand this is not an easy thing to fix. But I think using a word that is overloaded / misused in different APIs or contexts does not make this easier for the end user.
If you replace "latest" with "last" or "youngest" or "most recent" in the versionfilter context, this makes it more obvious to the end user that this is somehow date-related.
So this issue would only be about a change in the versionfilter, which would make this "sound the same" in all contexts. "Most recent" always gets you the most recent by date, if the API allows that. (If the API does not allow that,
latestdoes not make sense anyways and that would be a different problem).olblak commentedon Aug 24, 2026
That's the challenge here, it doesn't always mean the same thing and depends on the third API which could also change over time.
The versionfilter is shared by all plugins so on githubrelease the latest is the newest by publishing time, with the docker plugin the behavior change depending on what docker registry the image is published, for example images published on ghcr.io are sorted by publish time while dockerhub sort images lexicographically.
When using the kind "latest", Updatecli only retrieve a list of version from the api and return the last or first element depending on the situation.
I don't have strong objection about renaming "latest" to something else but I don't think it will make it the whole situation clearier, on top we'll have to deal with the deprecation workflow as we never introduce "voluntarilly" breaking changes.