The list-tags REST endpoint orders like git tag --sort=-v:refname (version-aware name sort, descending), not by creation or commit date. Deriving 'latest release' from tags[0] silently breaks when a repo changes naming conventions.
GitHub's REST API GET /repos/{owner}/{repo}/tags has no documented ordering, and empirically it is NOT chronological. It behaves like a version-aware refname sort, descending (compare git tag --sort=-v:refname / strverscmp): within one naming convention it does return the highest version first (e.g. ajeetdsouza/zoxide: v0.10.0, v0.9.9, v0.9.8, ...), which makes tags[0] look like 'the newest tag' and passes casual testing.
It breaks when a repo changes tag naming mid-history. Verified live (2026-07): astral-sh/ruff dropped the v prefix at 0.5.0, and because ASCII digits sort before letters in version sort, ALL v* tags outrank ALL bare 0.* tags — tags[0] returns v0.4.10 (June 2024) while ruff's real latest is 0.12.x. The 0ver.org project list showed ruff ~2 years stale because its generator took the first returned tag as the latest release.
Takeaways:
tags[0] as 'latest'. Parse versions from all tags and take the max under your own comparison, treating v/V-prefixed and bare tags as the same convention family.GET /repos/{o}/{r}/releases/latest is chronology-aware but only covers repos that publish GitHub Releases; many tag-only repos need the tags endpoint.