Shields: Version / Github / Tag badge shows incorrect latest SemVer release

[driesvints]

Are you experiencing an issue with...

• [x] [shields.io](https://shields.io/#/)
• [ ] My own instance
• [ ] [gh-badges NPM package](https://www.npmjs.com/package/gh-badges)

:beetle: Description

The badge below shows "v3.8.1" as the latest SemVer release for the Guzzle library which is incorrect because "6.3.3" is the latest release.

This seems to be an issue with shields not accepting non-prefixed versions as valid SemVer versions even though they are totally valid. There's nothing in the SemVer spec that states that you need to prefix your version.

:link: Link to the badge

:bulb: Possible Solution

The solution would be to properly resolve all SemVer versions and order them by their correct latest release and ignore any prefix.

[chris48s]

We are returning the latest (sorting by SemVer) tag for guzzle based on this API call: https://api.github.com/repos/guzzle/guzzle/tags 6.3.3 is not returned as a tag. The way GitHub presents tags and releases is a frequent source of confusion, but in this case 6.3.3 does look like it should be returned as a tag as well as a release.

Presence or absence of "v" is a red herring. In principle, if 6.3.3 were returned as a tag by https://api.github.com/repos/guzzle/guzzle/tags , that would be returned as the latest version:

> const { latest } = require('./lib/version.js')
> latest(['v3.8.1', '6.3.3']);
'6.3.3'

[calebcartwright]

What makes this all the more puzzling to me is that in the releases api response (https://api.github.com/repos/guzzle/guzzle/releases) the 6.3.3 release is shown, with a reference to the 6.3.3 tag 🤔

I think this is going to require some upstream help/fix on the GH side

[paulmelnikow]

Out of curiosity, do you know if those are annotated tags or lightweight tags?

How to check: https://stackoverflow.com/a/40499437/893113
One explanation of the difference: https://rem.co/blog/2015/02/12/git-the-difference-between-lightweight-and-annotated-tags/

TIL(!) about this distinction from the tag API doc, which says it only supports annotated tag objects – though, buyer beware, I'm not even sure matches my own experience.

Sort of aside, the release badge shows 5.3.3 😆which I guess is the latest release by date:
https://img.shields.io/github/release/guzzle/guzzle.svg

[driesvints]

The way GitHub presents tags and releases is a frequent source of confusion

Yeah, totally agree.

Out of curiosity, do you know if those are annotated tags or lightweight tags?

Seems like some are and some aren't: https://paste.laravel.io/43dfcbf1-f3a8-4af2-9fb4-8330fb82acd6

Sort of aside, the release badge shows 5.3.3 😆which I guess is the latest release by date:
https://img.shields.io/github/release/guzzle/guzzle.svg

This is actually the original reason I ended up here. I came to the conclusion that the releases badge showing the latest release by date is a valid approach so I thought that the tag badge was more appropriate. But then I found out it skipped non-"v" prefixed tags which didn't make any sense at all to me 😅

[walter-weinmann]

Strange behavior with

user : K2InformaticsGmbH
repos: dderl and imem

release shows an old version, release_pre shows the current version

[RedSparr0w]

I believe the GitHub API orders them by ASCII order, and only the top 30 are returned.
eg:

'v3.8.1' > '6.3.3' // true

and because there is more than 30 with the v naming scheme, we don't ever see the others.
So the problem is if you change the naming scheme of tags throughout a project and they use a lesser valued character as a prefix.
Not sure if there is a work around for this, other than maybe using the release badge.

[RedSparr0w]

@walter-weinmann I can't seem to reproduce this behaviour, Both are showing v3.2.0 for me.

Repo | Release | Release-Pre
:-- | :-- | :--
K2InformaticsGmbH/imem | |
K2InformaticsGmbH/dderl | |

[walter-weinmann]

Sorry, there must be quite a delay when creating a new Realease until it is visible.

Thanks - I'm fine now.

[driesvints]

@RedSparr0w like said above, release badge isn't an option because it's ordered chronological and not by latest version :-/

[the-j0k3r]

@driesvints see https://github.com/guzzle/guzzle/tags?after=4.0.0 fromv3.8.1 you dont prefix the v on tags.

What I know and recently discovered, is that tag badges wont update their version because the missing v prefix to the semantic version e.g. 1.2.3.
So tagging as v1.2.3 will update a tag badge, and tagging as 1.2.3 wont. See https://github.com/StylishThemes/GitHub-Dark-Script/blob/master/README.md which last tag of 2.5.3 no v prefix no longer updates the tag badge in readme.

I wonder where the fault lies, why the tab badges absolutely seem to require this v prefix to work, maybe someone here can shed some light into it.

Related issues. https://github.com/silverwind/ver/issues/3 and current discussion on removing this https://github.com/StylishThemes/Wikipedia-Dark/issues/59

@RedSparr0w would #3144 address this issue?

[driesvints]

@driesvints see https://github.com/guzzle/guzzle/tags?after=4.0.0 fromv3.8.1 you dont prefix the v on tags.

Yeah, I realize that. It shouldn't matter as both ways are valid tags or ways to indicate SemVer versions. Also: I don't maintain guzzle but noticed similar issues on the Laravel repositories.

[the-j0k3r]

It shouldn't matter as both ways are valid tags

Yes, but unfortunately it does matter, if you want the tag badges to update, my question is why cant the non prefixed version work just the same?

Im looking after a way to make it work without the v prefix, which I understand would likely solve the main issue on any repo.

Semantic versioning indicates though that v1.2.3 is not a valid semantic version, and suggests that the v1.2.3 would be a tag name only, yet the badge tags are left as you noticed, stale.

[driesvints]

Semantic versioning indicates though that v1.2.3 is not a valid semantic version, and suggests that the v prefix would be a tag name only, yet the badge tags are left as you noticed, stale.

Aha, didn't realize. Thanks for clarifying!

[chris48s]

We recently launched a new version of the GitHub tags badge which queries the GitHub V4 API for tags instead of using V3 tag API. That fixes this issue (and a bunch of other problems).

- Latest tag (sorted by date): https://img.shields.io/github/v/tag/guzzle/guzzle?sort=date
- Latest tag (sorted by semver): https://img.shields.io/github/v/tag/guzzle/guzzle?sort=semver

[driesvints]

Thanks!