Partial Release Deletion

[Pheotis]

Is your feature request related to a problem?

Currently, it is possible to combine multiple releases into a single version.
That is to say, separate files (by platform) may be uploaded into a single version release.
For plugins that have an instance and network component, it makes distribution much simpler!

Unfortunately, this creates the potential for mistakes. For example, please consider the following;

Problem Case One: Intended Uploads

|_ Release 1.0
| |_ Plugin_Paper-1.0.jar
| |_ Plugin_Waterfall-1.0.jar
|_ Release 1.1
| |_ Plugin_Paper-1.1.jar
| |_ Plugin_Waterfall-1.1.jar  
|_ Release 1.2
  |_ Plugin_Paper-1.2.jar
  |_ Plugin_Waterfall-1.2.jar

Let's pretend that Plugin_Waterfall-1.1 had some significant issue, but that Plugin_Paper-1.1.jar was fine.
It is presently impossible to remove the former without removing the latter.
It is possible to delete release 1.1, but that would also delete Paper_Plugin-1.1.jar, which was not the issue.

Problem Case Two: Spigot Confusion.

On spigot, the "BungeeCord" category exists, but is far weaker:
Assigning the "BungeeCord" tag to one's resource is merely an indication that the resource has some form of cross-server functionality (often using plugin messaging).

Users who are new to Hangar may mistakenly assume a similar behaviour exists, and assign a copy of their plugin to both platforms. Embarrassingly, I must admit that I was one such user (this is the resulting mess).

The resulting situation is far from optimal: even when the version in question has since been superseded, the mistaken and outdated version remains a drop-down option on the project's page.

Describe the solution you'd like.

The ability to delete Platforms without deleting releases, would be ideal:

The current system:

Rough mockup of the requested system:

Describe alternatives you've considered.

The other option is to delete the problematic version altogether.
This is suboptimal as:

• If this was a useful release, one would need to make a new, duplicate, release to fix this problem (resulting in an unnecessary, confusing, and annoying notification to anyone watching your project).

For example:
- 1.2
- 1.2 [DELETED]
- 1.1
- 1.0

• If this was an outdated and unsupported release, this still breaks continuity, which can be confusing or, if someone needs that old release for some reason, inconvenient.

For example:
- 1.4
- 1.3
- 1.2 [DELETED]
- 1.1
- 1.0

• If this was for an old, but still useful, release, this breaks continuity in an even worse -- and even more confusing -- way that could possibly confuse users into thinking an old release is new.

- 1.2
- 1.4
- 1.3
- 1.2 [DELETED]
- 1.1
- 1.0

Other

No response