Releases didn&#39;t display #884

Originally created by @lunny on GitHub (Jul 13, 2017).

Originally assigned to: @lafriks on GitHub.

see https://try.gitea.io/lunny/core/releases for examples. This repo is migrated from https://github.com/go-xorm/core. The counter is 8, but nothing listed.

Originally created by @lunny on GitHub (Jul 13, 2017). Originally assigned to: @lafriks on GitHub. see https://try.gitea.io/lunny/core/releases for examples. This repo is migrated from https://github.com/go-xorm/core. The counter is 8, but nothing listed.

GiteaMirror added the type/bug label 2025-11-02 03:40:16 -06:00

GiteaMirror closed this issue

GiteaMirror commented

@ethantkoenig commented on GitHub (Jul 18, 2017):

The problem is that the count is computed using GitRepo.NumTags(), whereas the list of releases is computed using the database. During the migration, the repo's tags are preserved, but no corresponding releases are added to the database.

We also don't generate/delete releases when tags are added/deleted. It seems there are two options

Enforce a one-to-one correspondence between releases and tags, by generating/deleting releases in the database when tags are added/deleted (including tags added during a migration)
Don't enforce such a one-to-one correspondence, and just compute the count using the DB. This seems like the easier option.

@ethantkoenig commented on GitHub (Jul 18, 2017): The problem is that the count is computed using `GitRepo.NumTags()`, whereas the list of releases is computed using the database. During the migration, the repo's tags are preserved, but no corresponding releases are added to the database. We also don't generate/delete releases when tags are added/deleted. It seems there are two options 1. Enforce a one-to-one correspondence between releases and tags, by generating/deleting releases in the database when tags are added/deleted (including tags added during a migration) 2. Don't enforce such a one-to-one correspondence, and just compute the count using the DB. This seems like the easier option.

GiteaMirror commented

@lafriks commented on GitHub (Jul 18, 2017):

I think the first option would be needed as otherwise mirrors will be missing releases

@lafriks commented on GitHub (Jul 18, 2017): I think the first option would be needed as otherwise mirrors will be missing releases

GiteaMirror commented

@lunny commented on GitHub (Jul 18, 2017):

As @lafriks said, I like the first option

@lunny commented on GitHub (Jul 18, 2017): As @lafriks said, I like the first option

GiteaMirror commented

@lunny commented on GitHub (Jul 26, 2017):

If we chose option 2, we need a new tab named tags. Tags is different with Releases, user could create Releases on Tags, user also could upload files to create Releases.

@lunny commented on GitHub (Jul 26, 2017): If we chose option 2, we need a new tab named tags. `Tags` is different with `Releases`, user could create `Releases` on `Tags`, user also could upload files to create `Releases`.

GiteaMirror commented

@lafriks commented on GitHub (Jul 26, 2017):

@lunny I plan to work on first option

@lafriks commented on GitHub (Jul 26, 2017): @lunny I plan to work on first option

GiteaMirror commented

@sapk commented on GitHub (Aug 4, 2017):

@lafriks any news ?
We could stick with option 1 we list tags and releases under release. Just if we found a release matching tag we display the attachements and formatted message in place of just the short message of tag. I think github does the same (even wrap successive tags without corresponding release).

@sapk commented on GitHub (Aug 4, 2017): @lafriks any news ? We could stick with option 1 we list tags and releases under release. Just if we found a release matching tag we display the attachements and formatted message in place of just the short message of tag. I think github does the same (even wrap successive tags without corresponding release).

GiteaMirror commented

@lafriks commented on GitHub (Aug 4, 2017):

@sapk I'm working on it, hope to finish on weekend

@lafriks commented on GitHub (Aug 4, 2017): @sapk I'm working on it, hope to finish on weekend

GiteaMirror commented

@lunny commented on GitHub (Aug 17, 2017):

@lafriks option 2 maybe an easier one. When importing, we can create release for every tags and inserted to databases. And on v1.3 we can add tags on Source, so that a release could be created from a tag. It's different from Github but more clear. And also it's easy to implement public release of private repo.

@lunny commented on GitHub (Aug 17, 2017): @lafriks option 2 maybe an easier one. When importing, we can create release for every tags and inserted to databases. And on v1.3 we can add `tags` on `Source`, so that a release could be created from a tag. It's different from Github but more clear. And also it's easy to implement public release of private repo.

GiteaMirror commented

@lunny commented on GitHub (Aug 23, 2017):

@lafriks since release/v1.2 created, please rebase and send PR to that branch.

@lunny commented on GitHub (Aug 23, 2017): @lafriks since release/v1.2 created, please rebase and send PR to that branch.

GiteaMirror commented

@sapk commented on GitHub (Aug 23, 2017):

@lunny I would say keep on master and backport.

@sapk commented on GitHub (Aug 23, 2017): @lunny I would say keep on master and backport.

GiteaMirror commented

2025-11-02 03:40:19 -06:00

@lafriks commented on GitHub (Aug 23, 2017):

I will keep it to master and then backport

@lafriks commented on GitHub (Aug 23, 2017): I will keep it to master and then backport

GiteaMirror commented

@lunny commented on GitHub (Aug 23, 2017):

@sapk @lafriks yes, you are right!

@lunny commented on GitHub (Aug 23, 2017): @sapk @lafriks yes, you are right!

GiteaMirror commented

2025-11-02 03:40:19 -06:00

@sapk commented on GitHub (Aug 23, 2017):

@lafriks do have open a PR even with un-finished work but that we can pre-review ? Can we do anything to help you ?

@sapk commented on GitHub (Aug 23, 2017): @lafriks do have open a PR even with un-finished work but that we can pre-review ? Can we do anything to help you ?

GiteaMirror commented

2025-11-02 03:40:19 -06:00

@lafriks commented on GitHub (Aug 23, 2017):

@sapk I will submit PR later today

@lafriks commented on GitHub (Aug 23, 2017): @sapk I will submit PR later today

GiteaMirror commented

@lcges commented on GitHub (Aug 25, 2017):

Hi.
How does the issue look? The last on the list :)

@lcges commented on GitHub (Aug 25, 2017): Hi. How does the issue look? The last on the list :)

GiteaMirror commented

@lunny commented on GitHub (Aug 25, 2017):

@qdbdbp also #2370 which will be back ported to v1.2. I will release v1.2.0-rc1 at first at #2388 merged.

@lunny commented on GitHub (Aug 25, 2017): @qdbdbp also #2370 which will be back ported to v1.2. I will release v1.2.0-rc1 at first at #2388 merged.

GiteaMirror commented

@lunny commented on GitHub (Aug 31, 2017):

This isn't fixed yet.

@lunny commented on GitHub (Aug 31, 2017): This isn't fixed yet.

GiteaMirror commented

@lafriks commented on GitHub (Aug 31, 2017):

Yes only point 2 is implemented

@lafriks commented on GitHub (Aug 31, 2017): Yes only point 2 is implemented

GiteaMirror commented

@lunny commented on GitHub (Aug 31, 2017):

@lafriks, So next, we only need copy tags to releases when migrating and add a button on tags to create a release.

@lunny commented on GitHub (Aug 31, 2017): @lafriks, So next, we only need copy tags to releases when migrating and add a button on tags to create a release.

GiteaMirror commented

@lafriks commented on GitHub (Aug 31, 2017):

Not only but I'm working on that. Anyway I think it should not be 1.2.0 blocker. This can be later backported to 1.2.1

@lafriks commented on GitHub (Aug 31, 2017): Not only but I'm working on that. Anyway I think it should not be 1.2.0 blocker. This can be later backported to 1.2.1

GiteaMirror commented

@bkcsoft commented on GitHub (Sep 1, 2017):

@lunny is the counter still 8? or is it 0?

@bkcsoft commented on GitHub (Sep 1, 2017): @lunny is the counter still 8? or is it 0?

GiteaMirror commented

@lafriks commented on GitHub (Sep 1, 2017):

@bkcsoft now counter is 0

@lafriks commented on GitHub (Sep 1, 2017): @bkcsoft now counter is 0

GiteaMirror commented

@bkcsoft commented on GitHub (Sep 1, 2017):

If so the bug would be fixed in my opinion. Gitea only imports the git repo, and Releases are metadata outside the repo.

@bkcsoft commented on GitHub (Sep 1, 2017): If so the bug would be fixed in my opinion. Gitea only imports the git repo, and Releases are metadata outside the repo.

GiteaMirror commented