Add Minecraft Version Information to Resources

Status

DarkKnights22

Professional Java Developer
Supreme
Feedback score
17
Posts
1,021
Reactions
350
Resources
14
I know that you already have the option to specify what server versions your resource works with, but it would be much cleaner and look more professional if it were like this:
upload_2019-10-5_0-2-7.png
 
Type
Suggestion
Status
Denied

Attachments

  • upload_2019-10-5_0-2-7.png
    upload_2019-10-5_0-2-7.png
    15.6 KB · Views: 68
PebbleHost
High performance, consistent uptime and fast support. Minecraft hosting that just works.

Justis

Community Member
Management
Feedback score
61
Posts
2,117
Reactions
2,414
Resources
0
When I was implementing the server versions section of our resource descriptions, this is what I had in mind, initially. However, it would require adding a new version every single time Minecraft updates. Moreover, you haven’t listed all Minecraft versions in that example. In reality, there would be far more to list. If you want to argue "Don’t list further back than 1.7 because those are obsolete", then what happens to all of the resources for 1.7 when 1.7 becomes obsolete, and we remove it from the list? Or are we not going to remove any, and just let the list of optional versions grow infinitely until it takes up the entire page?

Allowing the author to specify their version information is much cleaner. Especially when the author can concisely specify 1.7-1.14 instead of needing to check and list every single version in between the two.

Moreover, why are you mentioning what api version it was built against? It’s not very relevant to the people running it. All they need to know is what server versions your plugin will work with for them.

Especially after 1.13 came out, many creators package multiple plugin versions into their resources, so having a dropdown to select pre-defined versions wouldn’t work. They would need to specify that they offer multiple copies built against different api versions.

In the end, letting the author write their own info in, rather than pre-specifying for them is the better option.
 

DarkKnights22

Professional Java Developer
Supreme
Feedback score
17
Posts
1,021
Reactions
350
Resources
14
When I was implementing the server versions section of our resource descriptions, this is what I had in mind, initially. However, it would require adding a new version every single time Minecraft updates. Moreover, you haven’t listed all Minecraft versions in that example. In reality, there would be far more to list. If you want to argue "Don’t list further back than 1.7 because those are obsolete, then what happens to all of the resources for 1.7 when 1.7 becomes obsolete, and we remove it from the list? Or are we not going to remove any, and just let the list of optional versions grow infinitely until it takes up the entire page?

Allowing the author to specify their version information is much cleaner. Especially when the author can concisely specify 1.7-1.14 instead of needing to check and list every single version in between the two.

Moreover, why are you mentioning what api version it was built against? It’s not very relevant to the people running it. All they need to know is what server versions your plugin will work with for them.

Especially after 1.13 came out, many creators package multiple plugin versions into their resources, so having a dropdown to select pre-defined versions wouldn’t work. They would need to specify that they offer multiple copies built against different api versions.

In the end, letting the author write their own info in, rather than pre-specifying for them is the better option.
Ah, fair point tbh
 

Mick

BuiltByBit Owner
Management
Feedback score
28
Posts
6,412
Reactions
7,666
Resources
0
When I was implementing the server versions section of our resource descriptions, this is what I had in mind, initially. However, it would require adding a new version every single time Minecraft updates. Moreover, you haven’t listed all Minecraft versions in that example. In reality, there would be far more to list. If you want to argue "Don’t list further back than 1.7 because those are obsolete", then what happens to all of the resources for 1.7 when 1.7 becomes obsolete, and we remove it from the list? Or are we not going to remove any, and just let the list of optional versions grow infinitely until it takes up the entire page?

Allowing the author to specify their version information is much cleaner. Especially when the author can concisely specify 1.7-1.14 instead of needing to check and list every single version in between the two.

Moreover, why are you mentioning what api version it was built against? It’s not very relevant to the people running it. All they need to know is what server versions your plugin will work with for them.

Especially after 1.13 came out, many creators package multiple plugin versions into their resources, so having a dropdown to select pre-defined versions wouldn’t work. They would need to specify that they offer multiple copies built against different api versions.

In the end, letting the author write their own info in, rather than pre-specifying for them is the better option.
Denied, thanks for the suggestion
 
Status
Top