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.

[rezonant]

We just had this happen for one of our internal repositories, but when I edited an older release that was appearing at the top to have "[NOT LATEST]", it magically fixed itself, almost like it was a cached result of a bug that was previously fixed. So I re-edited the release to remove the NOT LATEST and everything is good now. The release that got stuck at the top was from August 9, 2023, and all further releases appeared below it until we edited the August 9 release.

[nishaatr]

Marking a release NOT LATEST or LATEST can fix the issue up to a point

We have a few releases which are out of order somewhere down the line and are already NOT LATEST. I can't reorder them even when using 'previous tag' option or resaving the offending releases without actually updating them.

I am still not sure what drives the ordering - the commit datetime? the tag creation date? the release creation time? We then have the 'same day release' which allegedly sorts by SemVer. In our case, marking a release to LATEST fixes the 'Latest' green link but not the ordering.

We occasionally make PATCH releases which will always have commit datetime later than the LATEST release but the SemVer version will be lower as its a PATCH and this messes the ordering

Another option is to recreate the tag with earlier date and then recreate the release mentioned here https://stackoverflow.com/questions/21738647/change-date-of-git-tag-or-github-release-based-on-it. I am not willing to try this as its too intrusive and error prone as an option in my opinion!

Its high time GH should address this:

• Fix the SemVer ordering (but this might not help non-SemVer releases where release names is not consistent)
• Provide user option to select the ordering (by SemVer, Commit datetime, release datetime, perhaps regex etc)
• Or perhaps the Releases page should allow manual ordering by simply 'click+hold' mouse and move the Releases in the order you wish
• And whats the point of 'same day' ordering?

[rezonant]

To be clear, when I say I marked it with "[NOT LATEST]", I mean in the title itself, not the "Latest" green tag you are referring to. I simply did a silly edit on the title of the release that was stuck at the top, and it fixed itself. No idea how widely applicable that is.

[nishaatr]

Sure. Understood.
I think the net effect of what you did was not the actual text edit that helped but likely the act of edit and resaving the release that did the trick - which I believe someone in the comments above has mentioned and seems to have helped (although I tried to no avail)

[mjaggard]

@rezonant That could have been number 3 from my comment #discussioncomment-7820616 - see the response I got from support on this. There's definitely >= 1 bugs here that need fixing.

[rezonant]

Yep, looks like the issue I had

[dinith-rusiru]

response 2#

[AdamBrousseau]

We've also hit this problem. I have tried editing older and the latest releases but nothing seems to work. The funny thing is we have 13 repos that all have the same release numbering scheme but only 1 repo is affected by this. Our repos only hold releases/binaries and a README, so the past several releases all are tagged based on the same commit. That could be contributing to why it's getting confused. But still odd that it's only happening on 1 of 13 repos.

[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!