Version 2.0 will drop support for Spigot and BungeeCord / Waterfall -- Must use Paper or Velocity

[A248]

The title tells you what you need to do.

For LibertyBans 2.0, we are planning to drop support for plain Spigot, BungeeCord, and Waterfall.

1. If you're using Spigot, you will have to switch to Paper.
2. If you're using BungeeCord or Waterfall, switch to Velocity.

[A248]

Benefits

1. Fewer platforms to support and debug; less conditional code
2. Expose Components in the Java API
3. BungeeCord and Waterfall are fundamentally broken when plugin listeners and commands are concurrently re-registered at runtime (affects /libertybans restart)
4. Can rely on Slf4j everywhere, without logging abstraction

These are small wins. There is a bigger motivation for this issue, I think, which I forgot to write down.

[octylphenol]

Hi, our server uses a fork of Bungeecord called XCord, how hard would it be to maintain a fork of LibertyBans with Bungeecord support?

[A248]

Very easy. In LibertyBans V1, it requires under 1,000 lines of code to support a new platform. To support V2, you would also need small changes to XCord:

1. Apply this thread safety patch to your fork. It fixes bugs caused by multithreading.
2. Provide the slf4j library.
3. Provide the kyori-adventure library. This is the one that offers net.kyori.adventure.text.Component. Then in your LibertyBans fork, write brief code to convert Component -> BaseComponent[].

Don't worry though. Version 2 is a complete rewrite and will be able to operate alongside V1 (connected to the same database). Also, V1 will be maintained and have bugs fixed for a long time, you'll just miss out on the latest features. Version 2 would likely come out in 6-8 years, I'd say.