Shields: github tag badges no longer showing pre-release tags
Since a few days github tag badges no longer show tags marked as "pre-release" (or tags without release info following a pre-release tag). Only tags marked as normal releases are shown (or tags following them).
Any idea what's going on?
groggemans
All 13 comments
Update;
It seems the pre-releases aren't the problem. The problem is in the tag names!
Works:
v1.0.0
Does not work:
v1.0.0-rc1v1.0.0-betav1.0.0-alpha
The tags that are no longer working used to get another color (dark orange/red). This indicated they're not normal releases.
groggemans
on 17 Apr 2016
Could you help me pinpoint the problem by giving me a link to a faulty badge?
Badges related to versions have implementation nastiness in them, because I have to detect whether versions need to be ordered according to semver, PHP's custom system, a generic version detection I wrote to handle most cases, and, as the last resort, ASCII ordering. I need more information to know which layer is impacted.
espadrine
on 3 Jul 2016
https://img.shields.io/github/tag/ellipsis/ellipsis-compiler.svg
Current tag for the badge is 'v0.0.2-Alpha', hope this helps!
Edit: As the project was released the above badge nolonger shows the problem.
groggemans
on 3 Jul 2016
I can confirm this bug.
chrisgorgo
on 11 Sep 2016
Would not this be expected behavior? Pre-releases are not releases.
The tag named v1.0.0 works because it's not a pre-release name.
May need a new badge for pre-releases.
ShyPixie
on 17 Nov 2016
It would be great to have pre-release badges. Interested to hear some updates on this one.
sfdeveloperhub
on 23 Feb 2017
Would someone like to dig into this and open a PR?
paulmelnikow
on 18 Apr 2017
Had a quick look and it's no longer working as before because the API no longer returns pre-releases when requesting the latest release. (https://developer.github.com/v3/repos/releases/#get-the-latest-release)
@paulmelnikow Just tested a successful fix. My idea is to make /github/release/user/repo.svg work for full releases, and add a new API endpoint /github/release/user/repo/all.svg that also works for pre-releases. Would that be ok?
_edit: changed proposal te default to full releases_
groggemans
on 23 Apr 2017
Returning the pre-releases by default seems reasonable (though not returning draft releases).
Do you see a need for a badge that excludes prereleases? I could see wanting "latest stable release", though a release could be non-prerelease without being stable.
paulmelnikow
on 24 Apr 2017
By the way, thanks for looking into this! Would be great to resolve this, one way or another.
paulmelnikow
on 24 Apr 2017
Pre-releases are often not intended for regular end-users. So defaulting to full releases only seems a good idea.
Projects targeted at devs or labels for technical sites like GitHub can then use the all endpoint which provides pre-release support.
I'll make some time this evening to open a PR.
groggemans
on 24 Apr 2017
Makes sense, I'm fine with that.
paulmelnikow
on 24 Apr 2017
@paulmelnikow PR #959
groggemans
on 24 Apr 2017
Related issues
rominf
路
3Comments
lukeeey
路
3Comments
salaros
路
3Comments
calebcartwright
路
3Comments
korenyoni
路
3Comments
Most helpful comment
Had a quick look and it's no longer working as before because the API no longer returns pre-releases when requesting the latest release. (https://developer.github.com/v3/repos/releases/#get-the-latest-release)
@paulmelnikow Just tested a successful fix. My idea is to make
/github/release/user/repo.svgwork for full releases, and add a new API endpoint/github/release/user/repo/all.svgthat also works for pre-releases. Would that be ok?