Releases out of order

[PHLAK]

Releases are displaying out of order and it seems to be a bit random. They're not sorted by date/time, commit or tag name.

[MylesBorins]

@PHLAK what is the repository you are referencing here? If releasees are made on the same day it is supposed to sort by SemVer, which might be falling apart here. It should also be sorting based on date of the tag / commit not the GitHub release.

[PHLAK]

This is a private repository, can I contact you (or someone else) directly?

[MylesBorins]

I am noticing that your tags are starting with release/. This could be contributing to the strange behavior (we expect valid semver or version strings in the tag).

@WillHalto PTAL

[WillHalto]

👋 I can take a look! What's the name of the repo?

[PHLAK]

Today this issue also affected the automatically generated release notes since it was using the incorrect release/tag (release/69.3) as the "latest release". Thus it added notes for already released features.

[yemexx1]

thanks, @calvinchilds, it makes sense now. Would be nice to be able to choose how releases in a repo should be sorted :)

[calvinchilds]

It is a bit opaque! cc'ing @MylesBorins for the feature request

[kaush-13]

@calvinchilds @MylesBorins is there a ticket I can subscribe to for this?

[dzsodzso63]

where CART.21.51.5 comes before CART.21.51.10

and then why CART.21.51.10 comes before CART.21.51.4 ?

[calvinchilds]

@dzsodzso63 that's because CART.21.51.4, having a date almost a full day before CART.21.51.10, is (likely) dated the day before CART.21.51.10. The semver ordering only kicks in if the releases are the same day - see other comment https://github.com/orgs/community/discussions/8226#discussioncomment-1728546

[eregon]

I also noticed this seemingly-random order on https://github.com/ruby/truffleruby-dev-builder/releases
That uses the same commit for all releases, but a different tag, and tags are on separate days (created at the time of the tag name).

[eregon]

I worked around it by using tags like v20210102.010203 instead of builds-20210102-010203

[database64128]

We also encountered this bug in https://github.com/Shadowsocks-NET/QvStaticBuild/releases. This project uses tags in nightly-yyyy-MM-dd format.

The wrong release order breaks our AUR package, since it uses a simple script to select the first (assuming the first is also the latest) release from the API, which is now one month behind the latest.

[pablonete]

We've found the reason, and we have a fix in progress.

[pablonete]

Verified today that releases are sorted as expected at https://github.com/Shadowsocks-NET/QvStaticBuild/releases

[SamMackrill]

This is not sorting right for me either:
gw2-alternator repo

[calvinchilds]

@SamMackrill I believe because the version starts with an upper case V, the sorting falls back to string sorting. The version is only parsed as semver if the first character of the version is exactly the lower case v.

[Chrimle]

@calvinchilds If that is the case, then the instructions on the release page should be updated.
Currently, it states:

It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0.0 or v2.3.4.

[MikeJerred]

I'm seeing my releases out of order with 1.0.0-beta.10 appearing after 1.0.0-beta.9

[ZauberNerd]

We also saw this behaviour with prerelease versions yesterday. Although it seems like today the sorting is working correctly again: https://github.com/xing/act/releases

[chrisui]

Not sure why v217 is coming before all of our other releases, upto the latest v240. A draft shows before at least. Eg. Ordering shows as Draft, v217, v240, v239, v238, and so on.

[pablonete]

Thank you for reporting, @chrisui. Can you link the repo so I can take a look?

[chrisui]

Thank you for reporting, @chrisui. Can you link the repo so I can take a look?

Unfortunately it's a private repo. Is there some other info I could try and provide?

[pablonete]

Perhaps check out the created_at value for the v217 release, as this is the date (without time) used to sort.
It can be best checked using the Releases API.

[horror-proton]

I got v4.10.0-alpha.3.10.geb2e56af appearing after v4.10.0-alpha.3.9.ge0d22139 (observed on the
same day)

[pablonete]

That's expected, because semver only cares about the first 3 numeric parts (v4.10.0 in your case), and then everything after the - is not parsed and only sorted alphabetically, so 3.10 goes before 3.9 because 1 goes before 9.

[horror-proton]

But I saw the introduction of semver 2.0.0 saying suffix of pre-release versions must also be compared

Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

https://github.com/semver/semver/blob/a4f21e1a6fdf7d1a78a2d965889d958f96b11b42/semver.md?plain=1#L129-L145

[pablonete]

I'm afraid that's not currently applied to Releases sorting. @MylesBorins 👀

[MylesBorins]

Our current implementation is a mix of Semver 2.0.0 and pep440 with the intent of supporting the largest number of projects possible on GitHub.com.

The two specifications have very different interpretations of how to handle postfix / pre-releases so we opted for alphabetical sort.

[Chrimle]

Could the instructions on the release-page be updated with this information? (Preferably also mention this "limitation")
Currently it states:

It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0.0 or v2.3.4.

[NickCraver]

FWIW, we're also seeing this behavior on https://github.com/StackExchange/StackExchange.Redis/releases - I can't really make sense of what's it's trying to do. I'd expect it to either respect the tag order (chronologically) or the version number - both are in the correct order and I created the releases (backfill) oldest to newest one day last week. Is there any way for us to get these in the correct order? For a while (I checked every release I added) the latest wasn't at the top which is very not-awesome. Any help would be appreciated!

[joelnotified]

We have an issue as well, where the release PRODUCT-14.1.2.2 is ordered before the pre-release PRODUCT-14.2.1.0-rc4

[asportnoy]

Also experiencing this. Tags are in the correct order but releases are in a very weird order.

[1ktribble]

Experiencing the same issue

[nascjoao]

Hi, @MylesBorins! Hope you are doing well!
I am experiencing the same issue @asportnoy reported.
Is this being addressed some way or sounds like a new issue?

[himself65]

same issue here

[gpunto]

Hello folks, we've been experiencing a similar issue for some time in a private repo. We create a new release weekly and have an old one from December 2022 "stuck" at the top of the list as if it were the latest release. The actual latest release is also tagged correctly as such.

Old release stuck at the top	Latest release appearing right after

I also checked the created_at through the Releases API as suggested above, and it matches what is shown in the UI:

• 2022-12-05T17:00:57Z
• 2023-05-02T06:01:43Z

[BdR76]

I think the same issue has happened in the CSV Lint repository

[yannduran]

Even tags are not always sorted correctly. See how v0.20.0 is out of order.

But the releases make no sense. I don't really want to have to have v0.20.0 instead of v0.20 as the release name, but even changing that seems to have no effect. My tags have the trailing .0, but I'd prefer to not to have them in the release names.

When I use gh release list (why is there no gh tag list btw?), I get the results below.

Before and after changing the v0.20 release name to v0.20.0).

I don't even have a created_at column. I even deleted several releases, and added them back in the order I'd expect to see them, but that made no difference. I hope that the created_at value isn't being given precedence over tag etc. Not everything happens in exactly the order we'd like.

My releases are listed in this order:

• v0.21 (draft)
• v0.20.3 (pre-release)
• v0.20 (prerelease) [with or without the trailing .0]
• v0.20.2 (prerelease)
• v0.20.1 (prerelease)
• v0.19.2 (prerelease)
• v0.19.1 (prerelease).

What I don't understand is if releases have an associated tag, why isn't that what gets used for sorting? My tags/release names are very simple compared to what others are using, but even those simple tags/release names are not sorting in any predictable order.

Is this going to be "fixed"? Or at least made predictable? As users, we don't seem to have any reliable way of making sure releases are sorted in any expected way.

[jcmcken]

This makes it incredibly painful to look through changelogs for projects that rely on Releases and don't have a separate CHANGELOG.md. The Releases search is also pretty bad so you can't even filter down to a specific version prefix

[dskecse]

I've reproduced this bug in https://github.com/dskecse/gh_releases_order_issue/releases with semver (version string) tags, e.g. v1.0.1.
Basically, same-day tags/releases are displayed in the correct semver order, but this order is broken for tags/releases created on different days, see more info.
cc @MylesBorins

[dskecse]

For tags created in the following order (oldest to newest):

• July 16th
  • v0.1.0
  • v0.2.0
  • v1.0.0
  • v1.0.1
  • v0.2.1
  • v1.1.0
• July 17th
  • v1.2.0
  • v1.2.1
  • v0.2.2

I'd expect the following order (latest first):

• v1.2.1
• v1.2.0
• v1.1.0
• v1.0.1
• v1.0.0
• v0.2.2
• v0.2.1
• v0.2.0
• v0.1.0

[nZeus]

It's not a problem to reproduce the issue.
The issue is easy to reproduce, and I believe not difficult to fix.
But there is simply not a single response from GitHub team in this thread (which was created almost 3 years ago).
I believe once GH was acquired by Microsoft, the product stopped to get the required attention.
I simply cannot imagine a topic like this to be ignored by GitLab - they would definitely solve it pretty fast.

[egvijayanand]

When multiple releases occur on the same day, the earliest release remains at the top, even when a subsequent release is designated as the latest.

You can have a look at a sample here.

Kindly fix this issue at the earliest.

[lucasoares]

I have a mono repository that contains multiple projects that are each one versioned separated. All releases/tags have a prefix (ex.: Applications/Configurations/v1.0.0, Applications/Configurations/v1.0.1-foo)

The semver happens but only after the prefix. Is there a way to consider this in the release sorting?

Thanks.

[ScribbleGhost]

I also have this problem. Four years later nonetheless...

[odlove]

Can't believe you github cannot do such a simple thing well

[schnuerle]

I've got the same issue as of today with this repo

https://github.com/openmobilityfoundation/curb-data-specification/releases

Note the release sorted to the top now (tagged 1.1.0-rc marked as pre release) was created weeks before the release created today that should be at the top (tagged 1.1.0 and marked as latest release).

[JanKrivanek]

Same issue

https://github.com/JanKrivanek/MSBuildStructuredLog/releases

v2.3.175-beta.1 appearing before v2.3.176-beta.1

Any way to manually influence the order?

[JanKrivanek]

So in my case the issue was caused by the fact that ordering was done chronologicaly based on commit times of linked tags. As I was creating the second release in the GUI - it created the tag on the main branch which was behind the feature branch I was releasing from

[schnuerle]

That is what happened in my example too. My tags for reference https://github.com/openmobilityfoundation/curb-data-specification/tags

But time of tag creation should not be the sole way to order releases, right?! I should be able to specify a release date (as I do in the release description).

[NorseGaud]

Same issue here: https://github.com/Wooly-AI/woolyai-client-libraries/releases

[sjpb]

Same issue spotted today in https://github.com/stackhpc/ansible-slurm-appliance/releases:

• v2.20
• v2.21.1 (latest)
• v2.21
• v2.19
  was going a bit mad trying to spot a typo but unless I've missed it ...

[sjpb]

Heh, no, still wrong for me on Chrome Version 149.0.7827.53 (Official Build) (64-bit)

[sjpb]

But actually - v2.20 isn't showing for you at all!

[NorseGaud]

Ghost in the list

[sjpb]

On a survey size of 2, it appears v2.20 only apperas if you are signed in to the org, then it appears at the top of the list.

[sjpb]

Apparently the GitHub iOS app shows all releases, in the correct order. So that's one thing.

[schnuerle]

Having the same problem here: https://github.com/openmobilityfoundation/mobility-data-specification/releases

The release candidate (2.1.0 Release Candidate - April 16) is ahead of the final release (2.1.0 - July 8) in the Release list, despite being created months before.

---

But the 2.1.0 release is flagged as the latest, even though it's not at the top.

---

Despite this, on the repo home page, the correct release 2.1.0 is correctly shown as the latest.

[rairulyle]

Same with us. Annoying! It should be sorted by release date!

[nZeus]

It's more complicated than that. Sorting by release date would place hotfix releases of older versions in front of the latest release.

[AukeTembrink]

Almost 5 years later and it still happens 💯

[Yave-Yu]

Why my releases sorts this weird way? 1.4 came first than latest 1.5 release, and I have no way to sort it manually!

[schnuerle]

I think this has been mentioned before, but just as a reminder for anyone who has the same issue: you simply need to set the "previous" version:

I have tried that and that does not work. 1) it does not save after you click "Update Release" and come back and 2) it's meant to be used when generating the release notes, not for ordering the releases.

[nZeus]

My bad, I thought this is the reason it works for us. I'll remove my previous comment 👍

[hamzahamidi]

Same problem on https://github.com/texaryn/texaryn/releases. This is a monorepo with independently versioned packages. @texaryn/schema-zod@0.1.2 appears below @texaryn/web-components@0.6.0, even though GitHub shows it was released later, at 21:12 UTC versus 18:51 UTC on October 11, 2026.

Could the Releases page offer a sort menu so readers can choose the order that fits the repository, for example by publish date, version or tag, or alphabetically by release name? A direction control would let readers choose newest first or oldest first for dates, and ascending or descending for names and versions. Filtering by package or tag prefix would also help in monorepos.