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.
lunny
All 26 comments
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
on 18 Jul 2017
I think the first option would be needed as otherwise mirrors will be missing releases
lafriks
on 18 Jul 2017
As @lafriks said, I like the first option
lunny
on 18 Jul 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
on 26 Jul 2017
@lunny I plan to work on first option
lafriks
on 26 Jul 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
on 4 Aug 2017
@sapk I'm working on it, hope to finish on weekend
lafriks
on 4 Aug 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
on 17 Aug 2017
@lafriks since release/v1.2 created, please rebase and send PR to that branch.
lunny
on 23 Aug 2017
@lunny I would say keep on master and backport.
sapk
on 23 Aug 2017
I will keep it to master and then backport
lafriks
on 23 Aug 2017
@sapk @lafriks yes, you are right!
lunny
on 23 Aug 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
on 23 Aug 2017
@sapk I will submit PR later today
lafriks
on 23 Aug 2017
Hi.
How does the issue look? The last on the list :)
lcges
on 25 Aug 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
on 25 Aug 2017
This isn't fixed yet.
lunny
on 31 Aug 2017
Yes only point 2 is implemented
lafriks
on 31 Aug 2017
@lafriks, So next, we only need copy tags to releases when migrating and add a button on tags to create a release.
lunny
on 31 Aug 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
on 31 Aug 2017
@lunny is the counter still 8? or is it 0?
bkcsoft
on 1 Sep 2017
@bkcsoft now counter is 0
lafriks
on 2 Sep 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
on 2 Sep 2017
~But how to create releases?~ Then we need a tags list on release create page?
lunny
on 2 Sep 2017
@lunny Yes, that would be the expected behaviour IMO
bkcsoft
on 4 Sep 2017
Possibly related: #3247
strk
on 21 Dec 2017
Related issues
haytona
路
3Comments
lunny
路
3Comments
ghost
路
3Comments
flozz
路
3Comments
BNolet
路
3Comments
Most helpful comment
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