Release ordering does not respect semantic versions #1465

New Issue

GiteaMirror · 2025-11-02T04:01:43-06:00

GiteaMirror commented

2025-11-02 04:01:43 -06:00

Originally created by @witten on GitHub (Jan 18, 2018).

Gitea version (or commit ref): d29aa76
Git version: 1.9.1
Operating system: whatever try.gitea.io is running
Database: whatever try.gitea.io is running
Can you reproduce the bug at https://try.gitea.io:
- [X ] Yes (provide example URL): https://try.gitea.io/testytesterson/release-ordering/releases
- No
- Not relevant
Log gist: N/A

Description

On a releases page, I expect the releases to be ordered either by their semantic versions or by reverse chronological order or both. E.g. 1.0.11, then 1.0.10, then 1.0.9.

Instead, Gitea appears to be ordering by some other criteria (reverse alphabetic sort?). In the example linked above, it's 1.0.9, 1.0.8, 1.0.12, etc.

It's possible that this is due to the way that I pushed the tags to the repository, which was: Make all the tags locally, and then git push --tags -u origin master. So pushing them in bulk instead of one at a time.

However, I would not expect the way that the tags were pushed to influence the ordering on the releases page. For instance, importing an existing project to Gitea from another project hosting service should result in a correctly ordered releases page.

Screenshots

Originally created by @witten on GitHub (Jan 18, 2018). - Gitea version (or commit ref): d29aa76 - Git version: 1.9.1 - Operating system: whatever try.gitea.io is running - Database: whatever try.gitea.io is running - Can you reproduce the bug at https://try.gitea.io: - [X ] Yes (provide example URL): https://try.gitea.io/testytesterson/release-ordering/releases - [ ] No - [ ] Not relevant - Log gist: N/A ## Description On a releases page, I expect the releases to be ordered either by their semantic versions or by reverse chronological order or both. E.g. 1.0.11, then 1.0.10, then 1.0.9. Instead, Gitea appears to be ordering by some other criteria (reverse alphabetic sort?). In the example linked above, it's 1.0.9, 1.0.8, 1.0.12, etc. It's possible that this is due to the way that I pushed the tags to the repository, which was: Make all the tags locally, and then `git push --tags -u origin master`. So pushing them in bulk instead of one at a time. However, I would not expect the way that the tags were pushed to influence the ordering on the releases page. For instance, importing an existing project to Gitea from another project hosting service should result in a correctly ordered releases page. ## Screenshots ![Example on try.gitea.io](https://i.imgur.com/Nv08MM5.png)

GiteaMirror added the type/proposal label 2025-11-02 04:01:43 -06:00

GiteaMirror closed this issue

2025-11-02 04:01:43 -06:00

GiteaMirror commented

2025-11-02 04:01:43 -06:00

@lafriks commented on GitHub (Jan 18, 2018):

Releases are ordered by their creation time

@lafriks commented on GitHub (Jan 18, 2018): Releases are ordered by their creation time

GiteaMirror commented

2025-11-02 04:01:44 -06:00

@witten commented on GitHub (Jan 19, 2018):

Ah, okay, thanks. If there's a way to change release creation time, then this ticket might not be necessary. But I don't see a way to do that without performing manual database surgery.

@witten commented on GitHub (Jan 19, 2018): Ah, okay, thanks. If there's a way to change release creation time, then this ticket might not be necessary. But I don't see a way to do that without performing manual database surgery.

GiteaMirror commented

2025-11-02 04:01:44 -06:00

@lafriks commented on GitHub (Jan 19, 2018):

It is tag creation time so you can change tag creation time in git and it would order correctly

@lafriks commented on GitHub (Jan 19, 2018): It is tag creation time so you can change tag creation time in git and it would order correctly

GiteaMirror commented

2025-11-02 04:01:44 -06:00

@witten commented on GitHub (Jan 20, 2018):

Okay, I was able to manually order the tags by deleting them all from the remote and then carefully creating them in order, one by one, e.g.:

git push -u origin :refs/tags/1.2.3
git push -u origin 1.2.3

But it would still be really nice not to have to do this. For comparison, a bulk git push --tags to another project hosting solution that shall go nameless (hint: it ends in "Hub") does not exhibit this problem.

@witten commented on GitHub (Jan 20, 2018): Okay, I was able to manually order the tags by deleting them all from the remote and then carefully creating them in order, one by one, e.g.: ``` git push -u origin :refs/tags/1.2.3 git push -u origin 1.2.3 ``` But it would still be really nice not to have to do this. For comparison, a bulk `git push --tags` to another project hosting solution that shall go nameless (hint: it ends in "Hub") does not exhibit this problem.

GiteaMirror commented

2025-11-02 04:01:44 -06:00

@thehowl commented on GitHub (Jan 20, 2018):

The only use case I see for this is for patch versions on older releases to fix critical issues. In layman's terms, the question is, should v1.1.4, published on the 1st of June, go before or after v1.2.0, published on the 1st of May?

Personally, I prefer the releases being listed in reverse chronological order, not following semver. Especially considering if a project does not use semver.

GitHub seems to simply use reverse alphabetical: https://github.com/thehowl/testrepo/releases

@thehowl commented on GitHub (Jan 20, 2018): The only use case I see for this is for patch versions on older releases to fix critical issues. In layman's terms, the question is, should `v1.1.4`, published on the 1st of June, go before or after `v1.2.0`, published on the 1st of May? Personally, I prefer the releases being listed in reverse chronological order, not following semver. Especially considering if a project does not use semver. GitHub seems to simply use reverse alphabetical: https://github.com/thehowl/testrepo/releases

GiteaMirror commented

2025-11-02 04:01:44 -06:00

@witten commented on GitHub (Jan 20, 2018):

The main use case I see is importing a Git project with existing tags into Gitea. That's where the aforementioned git push --tags simply doesn't result in the intended order on Gitea's release page.

@witten commented on GitHub (Jan 20, 2018): The main use case I see is importing a Git project with existing tags into Gitea. That's where the aforementioned `git push --tags` simply doesn't result in the intended order on Gitea's release page.

GiteaMirror commented

2025-11-02 04:01:45 -06:00

@thehowl commented on GitHub (Jan 20, 2018):

Unless you do what I said in my comment or as you posted in the first post, you have more than a tag per commit (why though?), it seems to work fine and sort by rev chronological order of each tag's commit: https://try.gitea.io/Howl/test/releases

@thehowl commented on GitHub (Jan 20, 2018): Unless you do what I said in my comment or as you posted in the first post, you have more than a tag per commit (why though?), it seems to work fine and sort by rev chronological order of each tag's commit: https://try.gitea.io/Howl/test/releases

GiteaMirror commented

2025-11-02 04:01:45 -06:00

@ghost commented on GitHub (Jul 31, 2018):

@techknowlogick believe this can be closed

@ghost commented on GitHub (Jul 31, 2018): @techknowlogick believe this can be closed

GiteaMirror referenced this issue

2025-11-02 11:57:47 -06:00

[PR #1465] [MERGED] Fix races within code.gitea.io/git.(*Command).RunInDirTimeoutPipeline #15916

Sign in to join this conversation.