The GitHub client only looks at the first 100 tags. In most cases, this should work fine because the response seems to be sorted in reverse lexicographical order, so the newest tag should usually be the first. However, if a repository uses multiple tag prefixes, such as v and st3-, then it might fail to find the latest tag for one of those prefixes.
This happened recently for JS Custom. ST3-compatible tags use the st3 prefix, but there were more than 100 tags using the v prefix, so all ST3 tags were pushed to the second page. This caused the package to be marked as missing. (https://github.com/Thom1729/Sublime-JS-Custom/issues/124) I fixed the immediate problem by deleting some older tags. The crawler soon picked it up and JS Custom is back online.
Probably, the GitHub client will need to fetch every page of tags in order to avoid this bug completely. The GitHub API call doesn't seem to permit custom sorting or filtering by prefix, and the default sort is technically unspecified. Alternatively, the client could assume that the result is sorted and stop fetching when it finds a tag for each prefix it's looking for.
Supersedes #142.
https://github.com/wbond/packagecontrol.io/blob/a0a94202de3504e8e35499656d198d5bb935c69f/app/lib/package_control/clients/github_client.py#L93
The GitHub client only looks at the first 100 tags. In most cases, this should work fine because the response seems to be sorted in reverse lexicographical order, so the newest tag should usually be the first. However, if a repository uses multiple tag prefixes, such as
vandst3-, then it might fail to find the latest tag for one of those prefixes.This happened recently for JS Custom. ST3-compatible tags use the
st3prefix, but there were more than 100 tags using thevprefix, so all ST3 tags were pushed to the second page. This caused the package to be marked as missing. (https://github.com/Thom1729/Sublime-JS-Custom/issues/124) I fixed the immediate problem by deleting some older tags. The crawler soon picked it up and JS Custom is back online.Probably, the GitHub client will need to fetch every page of tags in order to avoid this bug completely. The GitHub API call doesn't seem to permit custom sorting or filtering by prefix, and the default sort is technically unspecified. Alternatively, the client could assume that the result is sorted and stop fetching when it finds a tag for each prefix it's looking for.
Related: #41.