The API of anaconda.org is providing incorrect information about the latest version.

[akikuno]

When I tried to create a badge using shields for the version of the package registered on conda-forge, an old version (v0.3.1) was reported instead of the latest version (v0.4.1). I inquired about this issue with shields. https://github.com/badges/shields/issues/10177

Upon inquiry, it was found that the "latest_version" at https://api.anaconda.org/package/conda-forge/wslPath is "0.3.1", and the latest version, which is 0.4.1, is not reflected. Although version "0.4.1" is registered under "versions", why is "latest_version" showing as 0.3.1?

On top of that, in the wslpath-feedstock, the version is displayed as 0.3.1. On the other hand, the version displayed on anaconda.org is 0.4.1. I had asked conda-forge and they instructed me to post here

I would appreciate any guidance on how to address this issue.

### Tasks

[akikuno]

CC @jezdez @jaimergp (for awareness). Thank you in advance.

[jakirkham]

It is worth noting other info about the 0.4.1 is in the JSON output from the API call. Just for some reason latest_version was not updated when the new version was published. So this could be as simple as updating that field

[akikuno]

@jakirkham Thank you very much for your guidance! How can we update the field?

By the way, while I am unsure of the reason why latest_version was not updated, I suspect that one of the factors might be that when upgrading from 0.3.1 to 0.4.0, the file extension registered with Anaconda changed from .tar.bz2 to .conda.

https://anaconda.org/conda-forge/wslpath/files

[jakirkham]

Idk unfortunately. Am just another OSS contributor/user like you 🙂

The package format change is also interesting. We ran into a potentially related issue with the CDN on a different channel recently where a package format change affected CDN behavior ( https://github.com/conda/infrastructure/issues/945 )

[jezdez]

We're looking into it

[jaimergp]

Hm, the .conda / .tar.bz2 distinction is indeed interesting. My workaround for this in other projects is to sort all package entries by version using conda's VersionOrder as the key, but that might be infeasible for the shields API.

[jakirkham]

Even so, it seems reasonable that latest_version would be up-to-date

[jameslamb]

Linking some other relevant things.

• this was reported in anaconda/anaconda-client a few years ago: https://github.com/anaconda/anaconda-client/issues/561
• @StrikerRUS and I just observed an interesting case in conda-forge/lightgbm (https://github.com/conda-forge/lightgbm-feedstock/issues/59)
  • a few years ago, a SHA like bee59dd269a93b093f2c610d4a6683a7ea87c63d3ea35c622123ce2c020b2abc had accidentally been committed as the package version
  • the broken label was added for the packages from that version, but that SHA was still reported by https://api.anaconda.org/package/conda-forge/lightgbm in the latest_version field (all other package versions were 3-part semver like 3.5.0, 4.1.0, etc.)
  • after the changes in https://github.com/conda-forge/lightgbm-feedstock/pull/55, which affected the build strings of lightgbm packages, the API started correctly reporting 4.5.0 in latest_version

Hopefully those provide some clues to the root cause.

[akikuno]

@jameslamb

Thank you for your valuable comments! After upgrading the version of wslPath and updating the conda-forge feedstock, the latest_version is now correctly reflecting the latest version.

To be honest, the root cause is still unclear, but it might be related to the fact that the update was done by regro-cf-autotick-bot this time, while the previous version was updated manually, which could explain why the latest_version was not updated before.

https://github.com/conda-forge/wslpath-feedstock/pulls?q=is%3Apr+is%3Aclosed

In any case, the issue has been resolved, so I will close this.

Thank you for all your support.