[Proposal] Support release types #7645

New Issue

GiteaMirror · 2025-11-02T07:32:18-06:00

GiteaMirror commented

2025-11-02 07:32:18 -06:00

Originally created by @delvh on GitHub (Jul 31, 2021).

Currently, releases exist.

There is no differentiation between whether a release is a patch, a minor or a major version, something completely different, or none.
Having the ability to mark releases as i.e. one of those mentioned above can make a huge significance when displaying the releases to the user, i.e. by allowing for custom filtering, by adding a different display for releases of different types (e.g. such that major releases will be displayed more prominently than patch releases), or to show releases in a tree-like view where first the major versions comes, then when expanded the underlying minor versions and so on.

Also, when implemented such that releases know their hierarchical super-release (i.e. 1.16 would be the super-release of 1.16.2) and the super-release gets deleted, it could be possible to delete the sub-releases as well, although I do not know whether that is actually needed or wanted.

For now, it should simply be enough if the user can choose the release type himself when creating the repo or updating it (including a nil release type in case this release cannot be identified as belonging to any category). Here, user does not mean any user, but rather those with write-access for the repo or administrators only.

Later on, it could even be possible to autotag releases of repos that follow semantic versioning, i.e. by using a bot, a plugin, or even with built-in support. (I tend rather towards an external bot that simply listens to changes in the releases and updates these releases accordingly)

Originally posted by @delvh in https://github.com/go-gitea/gitea/issues/16585#issuecomment-890403388

Originally created by @delvh on GitHub (Jul 31, 2021). Currently, releases exist. There is no differentiation between whether a release is a **patch**, a **minor** or a **major** version, something completely different, or none. Having the ability to mark releases as i.e. one of those mentioned above can make a huge significance when displaying the releases to the user, i.e. by allowing for custom filtering, by adding a different display for releases of different types (e.g. such that **major** releases will be displayed more prominently than **patch** releases), or to show releases in a tree-like view where first the major versions comes, then when expanded the underlying minor versions and so on. Also, when implemented such that releases know their hierarchical super-release (i.e. 1.16 would be the super-release of 1.16.2) and the super-release gets deleted, it could be possible to delete the sub-releases as well, although I do not know whether that is actually needed or wanted. For now, it should simply be enough if the user can choose the release type himself when creating the repo or updating it (including a nil release type in case this release cannot be identified as belonging to any category). Here, user does not mean any user, but rather those with write-access for the repo or administrators only. Later on, it could even be possible to autotag releases of repos that follow semantic versioning, i.e. by using a bot, a plugin, or even with built-in support. (I tend rather towards an external bot that simply listens to changes in the releases and updates these releases accordingly) _Originally posted by @delvh in https://github.com/go-gitea/gitea/issues/16585#issuecomment-890403388_

GiteaMirror added the type/proposal label 2025-11-02 07:32:18 -06:00

GiteaMirror commented

2025-11-02 07:32:19 -06:00

@lunny commented on GitHub (Aug 10, 2021):

You can know if it's a minor release via that version number.

@lunny commented on GitHub (Aug 10, 2021): You can know if it's a minor release via that version number.

GiteaMirror commented

2025-11-02 07:32:20 -06:00

@noerw commented on GitHub (Aug 23, 2021):

I for one would like tags that aren't full releases to be auto-hidden ala Github except for the latest of course.

@mattatobin this should actually the case in 1.14+, see also #16720

@noerw commented on GitHub (Aug 23, 2021): > I for one would like tags that aren't full releases to be auto-hidden ala Github except for the latest of course. @mattatobin this should actually the case in 1.14+, see also #16720

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7645