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

[Mehdimome]

Hello

[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

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

[bensmind]

Same thing happening for us, very simple sem-ver tag style no letters or pre/postfixes.
Tags (and release creation dates) are all chronological:

But the releases show out of order:

[joshstoik1]

I just ran into this issue with one of my repos. Editing and resaving the out-of-order release (without making any changes) was enough to move it back into the correct position.

Hopefully that trick will help others!

[nishaatr]

Similar lineup with us - v5.3.2, v5.0.5, v5.1.7, v5.2.4....
I edited and resaved (no changes) v5.0.5, v5.1.7 and v5.2.4 but no change at all
Same issue whether logged in or not

[oycyc]

Helpful, thanks!

[JustinPedersen]

Hijacking here for visibility. If you edit the previous tag on the release, by default it's set to Auto, just set it manually and it seems to pick up the correct order from there.

[say8425]

That was super awesomely works!! Thanks!!

[da-mask]

Frustrated that this actually worked. Clicked Edit and then Update release on out of order releases fixed the issue. Thanks for the tip.

[luc1an24]

Joining the issue thread
The same thing is happening to us for some time now. Straightforward sem-ver tag style no letters or pre/postfixes.
Also, the editing and resaving of the out-of-order release doesn't help.

[shinebayar-g]

Thanks for your attention @MylesBorins

releases are sorted via date and fall back to semver if they were released on the same day
The Latest release always appears at the top.

I think this is the root of the bug. This inconsistent behavior is tripping all of us. I'd prefer just timestamp based releases. No special treatment for last day please 🙏

[gameraccoon]

I don't think that part is specifically is a bug though, but it seems that it triggers some bug. From what I've seen the issue starts reproducing when two releases created on the same day (one of the releases starts appearing in the beginning of the list from that moment on, even when there are more recent releases present weeks apart, until it is edited manually)

But I agree, there's no reason in treating releases from the same day with some special logic (how should that even work considering time zones?)

[gameraccoon]

A working at the moment example of this bug is
this release page: https://github.com/moodlehq/moodle-cs/releases
and this release on that page: https://github.com/moodlehq/moodle-cs/releases/tag/v3.3.7

More explanation here (tl;dr different users see the issue differently)
https://github.com/orgs/community/discussions/8226#discussioncomment-7221585

[luc1an24]

@MylesBorins thanks for response. Sure, here is the link: https://github.com/databox/framework

[luc1an24]

Hi @MylesBorins, is there anyone we can tag to get the timeline here?
This issue is quite annoying and many users have the same issue.
Thank you!

[mjaggard]

In my repo the rules described by @MylesBorins are not correct for the order of releases on our page. The top item was created a few weeks ago whereas newer versions appear straight afterewards (assuming the "date" referred to is the same as the one populated on the UI) it also has an earlier version number and is not a draft.

[egvijayanand]

https://github.com/egvijayanand/dotnet-maui-templates/releases

This is really a problematic issue, it should be in the descending order of datetime with the latest release on top of the first page.

It's very hard to predict the way in which it is displayed, very random in nature. Gets modified for every release.

Fix this at the earliest.

[JustinPedersen]

I was having this same issue on a smaller Repo. I think there is something wrong with the previous Tag being set to auto. I manually set it on a few releases and that's fixed my ordering issue on the releases page.

[nishaatr]

Interesting. Might try this.
Did you try with and without GitHub login? Not 100% sure but I think this plays a part.
Also, did you ask your colleague to check if its truly fixed?

[JustinPedersen]

@nishaatr I have just had a colleague test and it worked on their side too. I cant check without login as it is a private repo.

[nishaatr]

Good to know. Thanks

[nZeus]

Thank you @JustinPedersen! Indeed after I manually selected the previous tag on the version that was incorrectly put to the top of the Releases page -> it solved the issue.

I really hope Github Team takes a closer look at this scenario and provides us with a proper fix 🙏

[nishaatr]

At least we have a confirmed workaround. I will try it at some point
But GH should really look into this and fix it as its causing unnecessary headache

[egvijayanand]

Have tried both with and without login, the releases are ordered at random. This is very annoying.

Is there any option setting that controls this?

Checkout this page - Verify the pull request ids.

[nishaatr]

Don't believe so.

[ChanJuiHuang]

Hi github,
I suffer in the same problem. This is my release page .
Please help me to resolve it.

Thank you very much
Ray

[nishaatr]

I don't even see 2.1.4 unless I view directly https://github.com/ChanJuiHuang/go-backend-framework/releases/tag/v2.1.4
I am logged in. This behavior has been highlighted in previous comments I think.
May be try this https://github.com/orgs/community/discussions/8226#discussioncomment-7704448

GitHub don't seem to care :(

[ChanJuiHuang]

Thanks, I recover it!

[ToyKeeper]

Another "me too" here. After migrating a project to GitHub, I manually added releases one at a time from the beginning of the project in chronological order, making sure to add them in the correct order... but they are listed in a seemingly random order instead.

Each release title is a date in YYYY-MM-DD format, and it is linked to a tag in the same format but with a "r" at the beginning, like r2023-10-31.

Here is the order it shows releases right now:

• 2023-10-31 (latest)
• 2023-06-29
• 2021-10-25
• 2020-04-27
• 2023-10-01
• 2023-05-30
• 2022-10-21
• ... (26 more) ...

A simple asciibetical sort would work fine. Or sorting by the timestamp when the release was added. Or the ability to manually re-order them.

[mjvanmiddelaar]

I've noticed my releases are not in order - previously this was in the correct order.

[mjvanmiddelaar]

v1.2.0 (2 days ago)
v0.3.1 (Oct 2)
v1.3.1 (9 minutes ago)
v1.3.0 (5 hours ago)

etc.

[mjvanmiddelaar]

I checked set as latest release for different releases until the order was OK that solved it.

[mjaggard]

I think there are 3 issues with Releases:
Most would be fixed by editing the release, ensuring it is marked as "Latest" and saving it regardless of whether any change was made.

1. Releases on the same day can get out of order if the semver is not in order. Not sure if this is still an issue because nobody has complained for a while.
2. Releases might not have been marked as "Latest"
3. The release indicies can get out of sync. I got the below from Github Support:

Sometimes our release indices can get a little out of sync and need a nudge. I've rebuilt them to address this issue. Our engineering team is aware of this and is working to fix it in future releases.
If the issue comes up again, the workaround is to edit the release and click on Update release without making any changes. This should force a re-sync and the missing releases will re-appear.

[bradfol]

If the issue comes up again, the workaround is to edit the release and click on Update release without making any changes. This should force a re-sync and the missing releases will re-appear.

This workaround worked for me on a private repo, thanks

[grahame-student]

Doesn't work for me in a private repo, still seeing releases out of order

[nishaatr]

I have previously tried "Update release without making any changes" and that didn't help if I recall

I also tried setting 'Latest' which does work if the last release is truly Latest. But not the case if Release was a PATCH release for an existing release. In this instance we will manually go and reset last release to 'Latest' after PATCH version has been released but that still leaves the PATCH release out of order (e.g. v5.0.5). See https://github.com/hazelcast/hazelcast/releases

I have not tried suggestion made here https://github.com/orgs/community/discussions/8226#discussioncomment-7704448. This appears to work so will try this at some point

As for "Releases on the same day can get out of order if the semver is not in order", still might be an issue unless GitHub have fixed this explicitly. As I recall, either the git commit or Release datetime is used to sort, so for a PATCH release this will still be an issue I believe

[shinebayar-g]

Unless someone gets their attention on social media they ain't fixing it.

[egvijayanand]

Tags are properly ordered whereas Releases are incorrectly ordered (erratic).

With some suggested solutions, have tried updating the previous tag of a few releases but in vain because when I open the updated release once again, the value of the previous tag reverts to auto once again instead of retaining the edited value.

Seems like an issue in identifying the previous tag with the value of the auto set. Needs a fix at the earliest.

[nishaatr]

Just tried this and I see the same behavior. I thought this was proven to work.

[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