I just sent a long message (with relevant details) to GitHub support (via https://github.com/contact) before I found out about this GitHub community forum and noticed this post too.
We have the same issue with many of our open source repositories but just recently I noticed that it works correctly in some repos but not in most.
First I thought the issue is that in some repositories (web component repositories) we prefix the release tags with “v” as in “v1.2.3”, but in some (Java repositories) we tag the versions as “1.2.3” without a “v” prefix. I’m not so sure anymore if this is the issue or not, but I guess it might be.
Another cause might be how the release is created (via GitHub API or via the web UI). Our web component releases are created with our own command line tool that afaik uses the GitHub API to automatically create the release (with generated release notes), but on at least some of our Java components we create the releases more manually via GitHub web UI from the “Draft a new release” button and select a branch there. I think our CLI tool probably doesn’t use a branch as a reference but a specific commit hash instead (I need to check this).
Here’s a real example of a repo where “Latest release” seems to be incorrect:
Here you see that v2.4.9 was released first, and after that v2.3.8 was released. The ordering is logical so that v2.4.9 still shows on top on the page, but for some reason v2.3.8 still shows up marked as “Latest release” and also the /releases/latest link unexpectedly points to v2.3.8 though in our opinion it should point to v2.4.9.
I think this is how it has worked it GitHub at least for over a year if not more. I first discovered this problem more than a year ago.
However recently I noticed that in some repositories this seems to work more expectedly. See example:
Here we have releases 2.0.2, 1.3.1 and 1.0.7 which have been released in this order so 2.0.2 was released first and 1.0.7 is chronologically the newest release. They also show up in the expected order on the page 2.0.2 at the top but surprisingly here it also marks 2.0.2 as the “Latest release”.
So basically it works exactly as we would like in this latter example, but why doesn’t it work for the other above mentioned repository?
I can understand if there’s a technical reason that you can more easily figure out the correct “Latest release” if branches are used as reference when creating a release.
However I think GitHub should be able to make it work even if a commit is directly targeted when creating a release (if that is the issue).
I would expect that the greatest number stable release tag according to Semantic Versioning https://semver.org/ would always be shown as the “Latest release”, and greatest number of valid prerelease tag would be “Latest prerelease”. Now this is not always the case which is confusing.