Awesome project, which is really necessary - just a command that works!

[jobenvil]

This is not an issue or discussion point, moreover a gratitude message. Just came here to say you thank you very much for lastversion 🥇

I was struggling with this automatically update package issue many times and I got working solutions f.e. for cloudflared, node_exporter, etc, but not for building from source "NLnetLabs/unbound" if a newer version was tagged, thus building unbound every week and installing it, if the GitHub version was newer than the installed, because I could not safely resolve with my scripts the last release from GitHub. Just automatically building for nothing, in many cases.

I was playing with GitHub API and I feel like I've been missing something. While googling I found this statement, which sadly was true for "NLnetLabs/unbound" repo:

This looks really cool, but as noted by @ozbillwang and @rlewkowicz it's not always reliable. It appears that it depends on how the Dev creates their "releases".

From what I can gather it should always be reliable for projects which provide specific binary file formats (e.g. .deb as per the OP). But may not be reliable for repos which just provide a source code tarball/zipball (and even if it is now, may not be in the future).

FWIW it seems that the difference is whether or not the dev explicitly creates a "Release" via GH (which is required to include specific binary formats). Everytime a repo is tagged, a new source code bundle will automagically show up on the GH "Releases" page. However, these automagic "releases" will not appear via the API, nor via the https://github.com/:owner/:repo/releases/latest URL. They will only be visible via the projects Release webpage and/or via the API under repos/:owner/:repo/tags. And unfortunately, it can't be assumed that the tags are in chronological order... 😢

Later on, I saw your comment and it went much better when I checked the README of the project. Thanks for all explanations, they were useful for me.

[iainelder]

I just wanted to add my thanks :-)

A lot of awesome tools have a less-than-awesome installation and updating experience. If a tool publishes releases on Github then it's one of the better ones!

So a script for downloading the latest release from Github becomes an indispensible tool for someone who wants to keep their toolbox up to date.

brew is becoming fashionable as a way to solve this on Linux-based systems. I wanted to like brew on Linux, because it worked so well on macOS, but I just can't get over the fact that it wants to install a whole parallel set of tools that already ship with my system (Ubuntu 20.04). That's too much bloat for me.

P.S. Good call on the discussion board! Is this a new feature of Github? I've never seen it before. Many times I've wanted to thank authors for their software, but opening an issue never felt like the right way.

[dvershinin]

Can't like brew even on OSX because it follows the example of other tools which like to do a complete git clone of their entire repo (as opposed to a lightweight shallow clone). As a result, the tool itself takes sometime gigabytes of space, of which most is useless to the user (git history).

Tapping "homebrew/core" takes ages and tremendous network resources. On Linux, the initial setup leads to ~600MB used for just the bare "brew" command to be available.
So it's very yuck, but a necessary evil because there's no alternative I know to it on Macs...
Not to say that it compiles many things...

Someone needs to create a binary-based (similar to RPM on RHEL) repo for Macs...

Yep, discussion boards were introduced this year I think. GitHub is evolving.

[iainelder]

In brew's defense, it was Github who asked brew to stop supporting shallow clones because of the burden it generated on Github's side. Homebrew/discussions#226

But yes, as an end user, I find it a horrible waste of space and time as well.