Latest release isn't the real latest


I am facing an issue for now several weeks.


We have 3 branches to maintain (3 versions of a Software).

Those versions are 2.8.x, 18.10.x, 19.04.x

I’ve released two new versions on the 18.10.x and 19.04.x in order to do that I’ve started this way

  • Tag on branch 18.10.x + release on GitHub

  • Tag on branch 19.04.x + release on GitHub

I was expecting the 19.04.x version to be tagged as the latest but the 18.10.x is tagged as the latest.

Any idea on how to prevent this kind of behaviour and possibly change the “latest release” tag on the right version ?


1 Like

It’s hard to say what might be causing it without seeing the structure of the underlying repository. If it is a public repository, could you share a link? If it is private, you may want to reach out to private support at so they can take a deeper look.

Let us know!

Hi @lee-dohm 

Thanks for the reply much appreciate.

It is an Open Source project. Here is the link

The example I mentionned can be found here

The real latest version is the 19.04.3 (from tag)

Maybe the issue is linked to the fact that tags are pushed on different branches (18.10.x & 19.04.x)


Yes, part of it may be the branching structure, but also the commit tagged v18.10.6 was committed 11 days ago versus the commit tagged v19.04.3 was committed about a month ago, so in at least that sense v18.10.6 is the latest release.

I hope that helps!

I just sent a long message (with relevant details) to GitHub support (via 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: Screenshot 2019-08-02 at 15.05.02.png

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 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.