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.

1 Like

@lee-dohm Has this been resolved or improved in anyway by GitHub? This problem still exists. The Latest / Latest release tag is applied to the release with the newest timestamp. If anyone is using automation to against the latest release endpoints, or using badges that include the latest version of a release, then they will run into problems whenever patches/updates are done to previous major versions.


  • v4.2.1 is the latest release of the current major version.
  • A patch is applied to a previous major version, releasing v3.9.2
  • v3.9.2 is now listed as the latest release, when really v4.2.1 should be listed either as latest or as current (if a new label was created for something like this?).

GitHub could have the latest label be applied, by default, to the newest timestamped non-draft, non-prerelease releases, but needs to provide some kind of override option that would allow for a repository to skip labeling new releases and a re-label feature that allows a repo maintainer to label the latest major version release as latest.

Older version releases are not drafts, and are not prereleases. There doesn’t seem to be any guidance here, and it makes release automation difficult. I was made aware of this being a GitHub-platform problem when trying to get a feature added to the GitHub CLI: