It seems like the list of versions is manually maintained. This seems hard to scale and already is at the point where it would be hard to blame you for failing to notice that a release happened.

I'm hoping to use install-action to replace some similar code (in an unreleased project). However, remembering to update to the latest version seemed impractical to me, so my code auto-detected it using the github API + jq (jq is pre-installed on GHA runners). The code was something like this:

api_url="https://api.github.com/repos/$repo/releases/latest"
query='.assets[] | select(.name | endswith("x86_64-unknown-linux-gnu.tar.gz")) | .browser_download_url'

tarball_url="$(curl --proto '=https' --tlsv1.2 --retry 5 --retry-delay 10 -sfSL "$api_url" | jq -r "$query")"
# then fetch the tarball was fetched with 
# curl <same flags> "$tarball_url" | tar zxf -

This hard-codes several things which would need to not be hard-coded for install-action usage, but it may be useful as a starting point. (Also, I'm not good at sh, so this may do something that is not ideal in some way). But you get the picture.

Although, maybe it's not how you'd like to do it. There's an argument that auto-detecting the latest version in this way is fragile, both because it makes too many API requests, and because it breaks if a release happens without binaries. It also doesn't easily support usage with a checksum as required by #1.

So perhaps it would be better to instead automate the updates of install-action's version list in some manner. This seems harder to me though, but perhaps you have plans.

Anyway, sorry if my concern is misplaced and you do not think this will be a problem. I just felt a little bit bad adding to your workload by adding a new tool after I noticed that versions were hard-coded.

Thank you.