Plugin feedback loop

Is your feature request related to a problem?

Hard to know when the right time to remove a deprecated feature is

Describe the solution you'd like.

You can just search Github for a specific method usage across all repositories, if the repo is popular you can PR the new method, meaning you can remove the old one with peace of mind that it isn't being widely used, stuff like bukkit PlayerRecipeBookClickEvent is only being used by a couple plugins

Obviously you'd want to remove deprecated events upon each minecraft update though not in the middle of an update cycle.

Describe alternatives you've considered.

idk, this solution is genius though

Other

No response

[Malfrador]

Removal of deprecated methods isn't decided based on the popularity of them. Instead it depends on the viability of maintaining the methods, functionality (some things simply got removed from the game) and how Paper can provide compatibility and replacements for them.

Your example is deprecated simply because its a duplicate event. It might get removed if compatibility can be provided via asm-utils at some point, e.g. listeners to the old event can be redirected to the new one on a bytecode level.
And while the Bukkit API has always provided long-term backwards compatibility, sometimes the game changes in such a fundamental way that methods will have to be removed, no matter how popular they are.

Additionally, pure GitHub repo stats are pretty meaningless.

1. GitHub does not index all public repositories reliably.
2. There are plenty of plugins without publicly published source code, or with source code published on another platform.
3. Pure plugin count is a pretty meaningless metric without taking into account the popularity of the individual plugins and how the events are used in them.

Removal of deprecated methods isn't decided based on the popularity of them. Instead it depends on the viability of maintaining the methods, functionality (some things simply got removed from the game) and how Paper can provide compatibility and replacements for them.

Your example is deprecated simply because its a duplicate event. It might get removed if compatibility can be provided via asm-utils at some point, e.g. listeners to the old event can be redirected to the new one on a bytecode level. And while the Bukkit API has always provided long-term backwards compatibility, sometimes the game changes in such a fundamental way that methods will have to be removed, no matter how popular they are.

Additionally, pure GitHub repo stats are pretty meaningless.

1. GitHub does not index all public repositories reliably.
2. There are plenty of plugins without publicly published source code, or with source code published on another platform.
3. Pure plugin count is a pretty meaningless metric without taking into account the popularity of the individual plugins and how the events are used in them.

thoughts on taking top 20,000 spigotmc, modrinth, hangar plugins and extracting what features are in use and calculating a usage score for each deprecated for removal event/api method? i.e how many downloads the plugin using it has * how many plugins are using it
can also extract bstats id from the plugin and query bstats api to see how many active servers are using said plugin for an even more accurate score compared to download count

if i made a program that does this would you be interested at all? useful tool which can be used in deciding that something which is cumbersome to maintain can be removed without much pain

[Strokkur424]

A very very large amount of plugins are never uploaded. So it isn't really a fair comparison. Furthermore, as Malfrador already said, Paper doesn't "just" remove methods. Those decisions are based on other factors he listed.

Do you have any specific issue with why you do not want to have deprecated methods in-code? Because I don't think there is any real issue with having them there as long as they do not add maintenance time.

A very very large amount of plugins are never uploaded. So it isn't really a fair comparison. Furthermore, as Malfrador already said, Paper doesn't "just" remove methods. Those decisions are based on other factors he listed.

Do you have any specific issue with why you do not want to have deprecated methods in-code? Because I don't think there is any real issue with having them there as long as they do not add maintenance time.

most servers just download plugins from the internet, or will at most hire a dev to code something very specific and small, the reason i propose such a tool is because i think it will be useful on weighing the trade-off of supporting a tricky feature vs dropping support