Badge

[nathany]

I'd like to create a badge that displays the latest version in READMEs:

It would link to the package page on gopkg.in.

Having already done the badge for GoDoc, I'd be happy to take this on (when I have a spare evening or two).

[niemeyer]

Neat, thanks!

[spf13]

This is a great idea @nathany . Looking forward to it.

[GeertJohan]

Great idea indeed!

[nathany]

Just so you know, I probably won't get to this until September. Other priorities right now.

[nathany]

For now, this is focused on having a badge. We can follow up with providing information on how to get the badge.

Going through a handler that retrieves the highest ref from GitHub and then redirects to shields.io for the SVG may be expensive if it needs to be done on every request for the badge.

• Caching the highest version would complicate deployment (unless it's just in memory).
• Invalidating the cache would require a GitHub webhook which complicates things for users as well (unless it's just time based, which is less precise).

[GeertJohan]

Caching the highest version would complicate deployment (unless it's just in memory).

Can be done in-memory with a simple map[pkg]version (both strings)..
Update when 10s old, remove from cache when 1d old ?

Letting users connect a webhook before the badge will work isn't too userfriendly, but do-able... Then it's not required to get a list of all the branches from the github repo anymore..
The downside of updating based on webhook calls is ofcourse that you'd need to sync this information between the deployments.. @niemeyer was it loadbalanced or failover? In th second case it could still work fairly easy.

[nathany]

Something like that should work fairly well. I can start without any sort of caching and see how it goes. Still figuring out the code base though #26.

Right now it's possible to use gopkg.in with a repo that has the proper tags even if they aren't familiar with gopkg.in. To keep that ability, webhooks should be optional at best... if supported at all.

[eapache]

Any update on this? I'd really like to put a badge on some of my repos :)

[nathany]

Sorry Evan. I haven't looked at this at all in the past 6 months. :-(

[nathany]

As a work around, you can use Shields.io to create a custom badge, but you will have to update the version # manually with each release.

http://shields.io/

[montanaflynn]

If we expose an endpoint that returns a list of all[1] or even the latest versions based on username/repo I could add a badge to http://shields.io. I'll look into the code and see if I can add it myself. A good thing about this approach is that shields.io itself handles the caching.

[1] This would also close #12

[niemeyer]

I'd prefer to have the badge being served by gopkg.in itself because that's both easy and much more convenient, but I'm not against people using something else if they wish. Caching should be taken into account either way, though. We can't assume that people would not use the API if we provide it.

[nathany]

Though gopkg.in can still be applicable when using the vendor support that Go 1.6 is helping enable, I personally don't see myself using gopkg.in in the future (eg. https://github.com/go-fsnotify/fsnotify/issues/108). That is to say, I'll leave this idea open, but I have no plans to work on it. So long and thanks for the fish.

[niemeyer]

o/