Sune Keller

> If we're doing this, why not going all the way and letting `bin` handle pre-releases on install as well? That sounds reasonable, I'll add that in a moment.

The current approach uses a very minimal scoring method, which includes having the repo's name in the binary name or URL's basename. This _should_ already give priority to files that...

> > > - Score better archive files based on OS and Arch and don't prompt the user if we have a single high scoring file > - Save the...

> - When performing an update, check the tar files again and look for a match on the initially saved file. If yes, just use that same file. > >...

> Files with different OS / Arch should score 0 by default and we shouldn't present that option to the user (unless eventually overridden by a flag?). Currently, any asset...

> * match the `bin` host What does that mean? Do you mean the repo name? That's what we already do, but I suppose we can wait with giving that...

> > > I like the separation of config and bin-database, because it really feels like two different things. If that's the goal then I suggest a new PR for...

> Is this PR talking about github provider only? > Shall we add a flag for this? > Shall we warn the user that they're installing a pre-release? > What...

> What we need to keep discussing here is what happens there's a combination of release and pre-release. My personal preference would be to _not_ automatically get newer pre-releases. However,...

> adjusts scoring based on OS / extensions. I think that's missing here is to do something similar for files in tar / zipped files. Since we're not performing that...