[Proposal] Support release types

[delvh]

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 #16585 (comment)

[mattatobin]

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

[lunny]

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

[noerw]

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