Tags/Releases order #1973

jalbiero commented 2025年06月03日 20:29:43 +02:00

Comment

How are tags/releases sorted?

I expect that tags/releases will be shown respecting their semantic versioning order, ascending or descending, but in order. In my attached images, both, tags and releases, respected the order until I released the version v1.3.1 which is not on the top, but at the bottom of the list, why? I know that Github and Gitlab respect the aforementioned order, but not AzureDevOps.

### Comment How are tags/releases sorted? I expect that tags/releases will be shown respecting their semantic versioning order, ascending or descending, but in order. In my attached images, both, tags and releases, respected the order until I released the version v1.3.1 which is not on the top, but at the bottom of the list, why? I know that Github and Gitlab respect the aforementioned order, but not AzureDevOps.

Gusted commented 2025年06月06日 15:14:31 +02:00

@jalbiero wrote in #1973 (comment):

I expect that tags/releases will be shown respecting their semantic versioning

It is not shown according to any semantic versioning. Looking at the code, the order is not really specified to any other attribute, its up to whatever order the database returns the results in.

@jalbiero wrote in https://codeberg.org/Codeberg/Community/issues/1973#issue-1734249: > I expect that tags/releases will be shown respecting their semantic versioning It is not shown according to any semantic versioning. Looking at the code, the order is not really specified to any other attribute, its up to whatever order the database returns the results in.

jalbiero commented 2025年06月07日 22:02:10 +02:00

Hi @Gusted , thanks for your response/clarification.

Just for the record: AzureDevOps sorts tags/releases by alphabetic order, which is clearly wrong, e.g. v1.10.0 < v1.2.0.

Sorting by the creation date is good for releases and tags that do not align with the semantic versioning specification. And it can be a good workaround for semantic versioning tags (of course, adding a new tag in the middle of two of them will break the order, but, again, it is a workaround until a proper semantic ordering could be implemented).

Hi @Gusted , thanks for your response/clarification. Just for the record: _AzureDevOps_ sorts tags/releases by alphabetic order, which is [clearly wrong](https://developercommunity.visualstudio.com/t/sort-tags-by-create-date/1043916), e.g. `v1.10.0` < `v1.2.0`. Sorting by the creation date is good for releases and tags that do not align with the semantic versioning specification. And it can be a good workaround for semantic versioning tags (of course, adding a new tag in the middle of two of them will break the order, but, again, it is a workaround until a proper semantic ordering could be implemented).

Gusted commented 2025年06月09日 00:20:10 +02:00

I am not really sure how semantic ordering could be implemented - the ordering would have to be done in the database and it shouldn't mess up the order of releases that doesn't use semantic ordering, it feels like a big task.

I am not really sure how semantic ordering could be implemented - the ordering would have to be done in the database and it shouldn't mess up the order of releases that doesn't use semantic ordering, it feels like a big task.

fnetX commented 2025年06月10日 00:16:11 +02:00

I think the problem is that the time is missing for this entry.

All of the releases have a timestamp recorded, v1.3.1 has not. Did you do anything different for the creation of this release?

Here is an excerpt from the database for reference:

MariaDB [gitea_production]> select id, tag_name, title, created_unix from `release` where repo_id = '501125';
+---------+----------+--------+--------------+
| id | tag_name | title | created_unix |
+---------+----------+--------+--------------+
| 3478935 | v1.0.0 | v1.0.0 | 1748616777 |
| 3479706 | v1.1.0 | v1.1.0 | 1748628767 |
| 3481083 | v1.2.0 | v1.2.0 | 1748637996 |
| 3501000 | v1.3.0 | v1.3.0 | 1748874409 |
| 3506760 | v1.3.1 | v1.3.1 | 0 |
+---------+----------+--------+--------------+
5 rows in set (0.000 sec)

I think the problem is that the time is missing for this entry. All of the releases have a timestamp recorded, v1.3.1 has not. Did you do anything different for the creation of this release? Here is an excerpt from the database for reference: ~~~ MariaDB [gitea_production]> select id, tag_name, title, created_unix from `release` where repo_id = '501125'; +---------+----------+--------+--------------+ | id | tag_name | title | created_unix | +---------+----------+--------+--------------+ | 3478935 | v1.0.0 | v1.0.0 | 1748616777 | | 3479706 | v1.1.0 | v1.1.0 | 1748628767 | | 3481083 | v1.2.0 | v1.2.0 | 1748637996 | | 3501000 | v1.3.0 | v1.3.0 | 1748874409 | | 3506760 | v1.3.1 | v1.3.1 | 0 | +---------+----------+--------+--------------+ 5 rows in set (0.000 sec) ~~~

jalbiero commented 2025年06月10日 02:41:06 +02:00

@Gusted wrote in #1973 (comment):

I am not really sure how semantic ordering could be implemented - the ordering would have to be done in the database and it shouldn't mess up the order of releases that doesn't use semantic ordering, it feels like a big task.

For Releases I agree with you, they must be sorted by creation time. For Tags, it depends on if they use or not a semantic versioning. To support the later, a new column (with a calculated coefficient) should be added to the database.

Anyway, the creation time order solves the majority of use cases so I will be happy if it could be fixed someday. Thanks.

@Gusted wrote in https://codeberg.org/Codeberg/Community/issues/1973#issuecomment-5051778: > I am not really sure how semantic ordering could be implemented - the ordering would have to be done in the database and it shouldn't mess up the order of releases that doesn't use semantic ordering, it feels like a big task. For Releases I agree with you, they must be sorted by creation time. For Tags, it depends on if they use or not a semantic versioning. To support the later, a new column (with a calculated coefficient) should be added to the database. Anyway, the creation time order solves the majority of use cases so I will be happy if it could be fixed someday. Thanks.

jalbiero commented 2025年06月10日 02:50:19 +02:00

@fnetX wrote in #1973 (comment):

I think the problem is that the time is missing for this entry.

All of the releases have a timestamp recorded, v1.3.1 has not. Did you do anything different for the creation of this release?

Here is an excerpt from the database for reference:

MariaDB [gitea_production]> select id, tag_name, title, created_unix from `release` where repo_id = '501125';
+---------+----------+--------+--------------+
| id | tag_name | title | created_unix |
+---------+----------+--------+--------------+
| 3478935 | v1.0.0 | v1.0.0 | 1748616777 |
| 3479706 | v1.1.0 | v1.1.0 | 1748628767 |
| 3481083 | v1.2.0 | v1.2.0 | 1748637996 |
| 3501000 | v1.3.0 | v1.3.0 | 1748874409 |
| 3506760 | v1.3.1 | v1.3.1 | 0 |
+---------+----------+--------+--------------+
5 rows in set (0.000 sec)

Hi @fnetX,

I created the Release/Tag in the same way as the others, but I created them twice.: When I noticed the first time that the order was wrong, I deleted them (tag and release). Then I recreated them again, but the problem persisted.

@fnetX wrote in https://codeberg.org/Codeberg/Community/issues/1973#issuecomment-5063463: > I think the problem is that the time is missing for this entry. > > All of the releases have a timestamp recorded, v1.3.1 has not. Did you do anything different for the creation of this release? > > Here is an excerpt from the database for reference: > > ```text > > MariaDB [gitea_production]> select id, tag_name, title, created_unix from `release` where repo_id = '501125'; > +---------+----------+--------+--------------+ > | id | tag_name | title | created_unix | > +---------+----------+--------+--------------+ > | 3478935 | v1.0.0 | v1.0.0 | 1748616777 | > | 3479706 | v1.1.0 | v1.1.0 | 1748628767 | > | 3481083 | v1.2.0 | v1.2.0 | 1748637996 | > | 3501000 | v1.3.0 | v1.3.0 | 1748874409 | > | 3506760 | v1.3.1 | v1.3.1 | 0 | > +---------+----------+--------+--------------+ > 5 rows in set (0.000 sec) > ``` Hi @fnetX, I created the Release/Tag in the same way as the others, but I created them twice.: When I noticed the first time that the order was wrong, I deleted them (tag and release). Then I recreated them again, but the problem persisted.