Multiple Recommended Versions

[Katrix]

It would be neat if there was support for displaying the recommended version for more than one version of SpongeAPI (or minecraft in the case of mods).

I don't think it's that important for sponge plugins as the goal will be to minimize API breakage in the long run from what I understand. However for Forge mods, which can normally only be used on a few or one specific version of minecraft, it's a big hassle to have to try to find the recommended version for your minecraft version.

The way I see it is that for Sponge, it would group them by the api, while for Forge it would just group them after the minecraft version.

---

Edit by @phase: See the current proposal here.

[phase]

I'd like to make recommended versions per-channel instead of per-verision.

This will allow us to combine tags for projects to display on the front page. I've got an algorithm in mind to sort them.

[mbax]

Make sure to preserve disallowing recommended for a channel marked as non-reviewed.

[phase]

I would still like to hear input on this.

@dualspiral brought up the idea of having multiple jars per version. I think this will unnecessarily complicate things. Having one jar per version means we can separate versions from each other.

Let's say I have a plugin called PhaseHome, and I have Sponge API 7, 8, and BungeeCoord specific variants. Let's also say that the differences between API 7 and 8 are too great to be able to put in one jar, so we need these in separate jars. That's 3 jars per version.

Our current way to display this is as such:

Name	Channel	Tags
1.0.1-bungee	Bungee	BungeeCord
1.0.1-sponge8	Sponge8	Sponge: 8
1.0.1-sponge7	Sponge7	Sponge: 7
1.0.0-bungee	Bungee	BungeeCord
1.0.0-sponge8	Sponge8	Sponge: 8
1.0.0-sponge7	Sponge7	Sponge: 7

The channels here can be anything the user wants. We could put both the Sponge versions in one channel, but if I were making this plugin this is how I would do it.

I believe that flattening the versions instead of hiding version specific jars would help eliminate confusion. Users can even filter by channel to get download links to the exact things they want. Having multiple jars per version could muddy things up and cause confusion, but if we can figure out a system that works I'd be okay with that. If we were to redo versions, though, it would be a radical change to the core models of Ore. If we deem this is the best course of action for Ore, we can do it, but it would take quite a bit of rewriting.

I believe recommended versions per channel with an active / inactive state is a great alternative to everything that has been lacking. I posted this in the staff channel the other day (edited a little bit for context):

Active: [SpongeForge XX] [Forge XX]
Active: [Sponge 8]
Active: [Sponge 7]
Inactive: [Sponge 6]
Active: [Lantern XX]

So let's say a user has these channels. This would get condensed to
[SpongeForge XX] [Forge XX] [Sponge 7, 8] [Lantern XX]

This is obviously a crazy amount of tags to put on the front page. What's interesting about these tags is that Forge and Sponge are probably the most important, and they have the least "platform priority"

Platform Priority is what determines which platforms override others (SpongeForge overrides SpongeCommon overrides Sponge, Paper overrides Spigot overrides Bukkit (not implemented))

We can use this to filter out tags and only display the platforms in a platform category with the lowest priority.
Meaning this would cut off Lantern and SF as they are higher than Sponge
[Forge XX] [Sponge 7, 8]

This is most likely the best information we can give the user. We say it works on these platforms, and when they go to the versions page they get more specific platform options.
What's good about this method is that if a plugin only works on SpongeForge, we would only display SpongeForge as it wouldn't have a Sponge API tag to display, since it would need a version with it in a separate channel. But if it has a Sponge API channel and a SpongeForge channel, it'll display the Sponge API tag because that's the most generic platform it can go on.

I still believe that this is the best course of action. This will allow us to display the information the user wants on the front page. And, using the information we've collected from the tags, we can filter by Sponge API version (#294).

As this is a core part of Ore, I would like a lot of developer and community input as to what action we should take. I believe the system I have described (having recommended versions be per channel and optionally being active to be condensed onto the front page and other plugin lists) is simple to implement, provides users the best information up front, and will help users search for the plugins they want. and then after that we can implement machine learning

Again, I would love to hear input from anyone who reads this issue. I'm going to post it in the Discord channels to get some input.

[ryantheleach]

I think phases suggestion also makes more sense, as multiple jars per version makes reviews difficult; the workflow for the average user would be to update API 5 build, upload, update API 7 build, upload, which now means that versions need to be editable to add more jar's which would require way too much refactoring.

Especially considering the review status is tied largely to versions.

Elsewise they would be releasing multiple versions anyway, to fit their workflow, which means you would also need multiple RB per channel.

So it's far easier to do it per channel.

I'm not saying that multiple jar's shouldn't be looked at per version as a feature, but a single version should be a single release.

Cross SpongeAPI builds is usually (for most plugin developers), multiple releases.

Multiple jars per version should be for things like, a webserver component of a plugin, or a UI for perms editing, or an API provided by your plugin service, if you don't want it all in one jar.

Future work / pain points could be:

Splitting a channel, e.g. you have 1 main channel, and when the new API release is out, you want to move all the versions to a different (compatible rules, non-review etc) channel.

Assigning a channel an API version for display purposes?

Promotion of release candidates to releases via channels? idk.