Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version / Github / Tag badge shows incorrect latest SemVer release #3080

Closed
1 of 3 tasks
driesvints opened this issue Feb 22, 2019 · 15 comments
Closed
1 of 3 tasks

Version / Github / Tag badge shows incorrect latest SemVer release #3080

driesvints opened this issue Feb 22, 2019 · 15 comments
Labels
question Support questions, usage questions, unconfirmed bugs, discussions, ideas

Comments

@driesvints
Copy link

Are you experiencing an issue with...

🪲 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 to the badge

Latest Version

💡 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
Copy link
Member

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'

@chris48s chris48s added the question Support questions, usage questions, unconfirmed bugs, discussions, ideas label Feb 22, 2019
@calebcartwright
Copy link
Member

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
Copy link
Member

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
Copy link
Author

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
Copy link

Strange behavior with

user : K2InformaticsGmbH
repos: dderl and imem

release shows an old version, release_pre shows the current version

@RedSparr0w
Copy link
Member

RedSparr0w commented Feb 28, 2019

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
Copy link
Member

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

Repo Release Release-Pre
K2InformaticsGmbH/imem GitHub release GitHub release-pre
K2InformaticsGmbH/dderl GitHub release GitHub release-pre

@walter-weinmann
Copy link

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

Thanks - I'm fine now.

@driesvints
Copy link
Author

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

@the-j0k3r
Copy link

the-j0k3r commented Apr 10, 2019

@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. silverwind/versions#3 and current discussion on removing this StylishThemes/Wikipedia-Dark#59

@RedSparr0w would #3144 address this issue?

@driesvints
Copy link
Author

@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
Copy link

the-j0k3r commented Apr 10, 2019

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Support questions, usage questions, unconfirmed bugs, discussions, ideas
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants