search

badges / shields

Concise, consistent, and legible badges in SVG and raster format
https://shields.io
Creative Commons Zero v1.0 Universal
23.82k stars 5.51k forks source link

Packagist version numbers slow to update #2435

Open danmcadams opened 5 years ago

danmcadams commented 5 years ago

Are you experiencing an issue with...

:beetle: Description The version number on my packagist shield is not being updated, it is however the most recent version when you go to the page on packagist. I checked the other issues here and they don't seem to line up with my issue. My versions are tagged exactly the same, and I have no version listed in composer.

Current version is v0.1.0 and my shield shows v0.0.1

The repository in question is here: https://github.com/The-Road-Bunch/command-menu

:link: Link to the badge https://img.shields.io/packagist/v/theroadbunch/command-menu.svg

:bulb: Possible Solution

paulmelnikow commented 5 years ago

Hi! Thanks for the report.

Confirmed. It looks like there is some lag. The new version is not reflected in the endpoint we're hitting:

https://packagist.org/packages/theroadbunch/command-menu.json

Based on the doc here https://packagist.org/apidoc#get-package-data it's cached for 12 hours, which explains the issue.

Maybe the version badge could be modified to use the "always up to date" endpoint those docs mention, instead:

http://repo.packagist.org/p/theroadbunch/command-menu.json

danmcadams commented 5 years ago

Interesting stuff, thanks for the quick response. I thought it may be a caching issue so I went to my package on packagist and the correct version was shown. Oh well, at least now I know.

Thanks again

paulmelnikow commented 5 years ago

@chris48s Do you know any reason (other than historical) that we might be using the dynamic endpoint for the version?

chris48s commented 5 years ago

No. Some of the packagist badges use /p and some use /packages but I don't think there is any solid reason for that (although note that the format of those 2 endpoints is slightly different so we'd need to modify the parsing code a little bit to change).

platan commented 5 years ago

I think we can switch to "Composer metadata" (https://packagist.org/apidoc#get-package-data). It will be beneficial for Shields and for Packagist. About Composer metadata:

This is the preferred way to access the data as it is always up to date, and dumped to static files so it is very efficient on our end.

calebcartwright commented 5 years ago

Sounds like a win-win

piekar294 commented 5 years ago

HI, i would like to work on this today :)