0neGal / viper

Launcher+Updater for TF|2 Northstar
https://0negal.github.io/viper
GNU General Public License v3.0
152 stars 21 forks source link

Add badges to README #121

Closed GeckoEidechse closed 2 years ago

GeckoEidechse commented 2 years ago

Rendered: image

I'm making this as a draft as I don't think we need both total downloads and latest, neither do I like the current placement but I couldn't come up with a better one. Also the badges kinda take attention away from FAQ and Releases.

So I'm happy to take feedback for both ^^

0neGal commented 2 years ago

I don't think we need both total downloads and latest

Agreed.

Another thing to consider is that the download numbers are not accurate, about half of all the downloads is just from the latest.yml and latest-linux.yml

I may just have to make my own badge generator that excludes those, which would also allow us to have more unique badges.

GeckoEidechse commented 2 years ago

I may just have to make my own badge generator that excludes those, which would also allow us to have more unique badges.

That.... sounds like overkill, ngl :P

I'd personally just go with the latest downloads, cause will boosted, seems to be still somewhat useful to get a grasp of the Viper user base.

GeckoEidechse commented 2 years ago

Also, I'm curious why the yml files. Does Viper client for some reason maybe download them?

0neGal commented 2 years ago

That.... sounds like overkill, ngl :P

Quite possibly... lol

Also, I'm curious why the yml files. Does Viper client for some reason maybe download them?

It's used for updates :)

GeckoEidechse commented 2 years ago

Also, I'm curious why the yml files. Does Viper client for some reason maybe download them?

It's used for updates :)

Hah, so I guess we're inflating our own stats then, lol

GeckoEidechse commented 2 years ago

Actually, couldn't we get latest release from https://api.github.com/repos/0neGal/viper/releases/latest? Or do we not do that due to potential API limits?

0neGal commented 2 years ago

Hah, so I guess we're inflating our own stats then, lol

Kinda it's just how electron-updater works :p, but technically yeah...

0neGal commented 2 years ago

Actually, couldn't we get latest release from https://api.github.com/repos/0neGal/viper/releases/latest? Or do we not do that due to potential API limits?

Quite frankly I don't wanna have to build our own updating system, and an inflated download stat is not really a downside that's big enough for me to want to build it, therefore it's easier to use electron-updater, let it do its thing which is mostly automatic, and so on.

As for API limits, we only ask electron-updater to check for new releases if there's passed more than 15 minutes since last check.

GeckoEidechse commented 2 years ago

Fair enough. (I don't have enough understanding of how electron-updater works under the hood, so I just assumed it was as simply as using a different source of truth for newest release ^^)

0neGal commented 2 years ago

Essentially the yml files have all the needed info to check for updates, SHA hashes, file sizes, dates and so on, simply relying on the version number won't be very useful.

And since GitHub's API provides very little information about release files it's sort of necessary, unless we want to just assume the version numbers are always right and can never be wrong.

0neGal commented 2 years ago

I've moved the badges into the "Install" section, personally I think it looks better, so if this is good with you I'll merge...

GeckoEidechse commented 2 years ago

Fine by me ^^

Completely forgot about this PR, imma move it out of draft move. Feel free to fix the merge conflicts :P

GeckoEidechse commented 2 years ago

Might be wise to remove the total downloads number as it's not really representative as you said ^^

GeckoEidechse commented 2 years ago

Actually we could probably also add a badge for Flathub: ![Flathub](https://img.shields.io/flathub/downloads/com.github._0negal.Viper?label=Flathub%20installs)

Flathub

0neGal commented 2 years ago

Might be wise to remove the total downloads number as it's not really representative as you said ^^

Hmm, but neither is the "Latest Release Downloads" number, should that one be removed as well maybe? Along with the Flathub installs, we can just have it be that and current version and project license.

Granted both of those aren't actually useful as both can be seen in the sidebar of the repo page anyway :p

Perhaps some latest commit or just commit count would be more useful, I honestly don't know.

GeckoEidechse commented 2 years ago

Hmm, but neither is the "Latest Release Downloads" number, should that one be removed as well maybe?

Yesn't. I'm gonna claim that "Latest Release Downloads" while still not accurate is (depending on update frequency) closer to actual user base and gives a sort of "authenticity" to the project. ^^

0neGal commented 2 years ago

Yesn't. I'm gonna claim that "Latest Release Downloads" while still not accurate is (depending on update frequency) closer to actual user base

Not really, while it's certainly more accurate, doing the math on the last two releases, about 34-35% of the downloads alone were the latest.yml file, and in all releases together it's about 40%

and [it] gives a sort of "authenticity" to the project. ^^

This I agree with.

Overall, I do think some count of the downloads is helpful to the end user, as you say, to give the project some authenticity. Perhaps a layout could be: release number, release downloads and flathub downloads ?


GitHub release (latest by date) GitHub release downloads (latest by date) Flathub Download (Total)

0neGal commented 2 years ago

bump

GeckoEidechse commented 2 years ago

Whoops, forgot to respond. Yeah suggestion looks good to me ^^

0neGal commented 2 years ago

Lovely, I'll just merge this then! :)