Hello,
Hard forking CloudburstMC/Protocol is probably not as good of an idea as you think it is. The upstream project has commercial backing and has certain requirements for a reason.
For example, the library supports Java 8 as a minimum because this enables compatibility with the widest array of software. It is still quite common for Java libraries to target Java 8.
I believe you forked this because you were frustrated with the slow review times for PRs such as with your Javadoc PR CloudburstMC/Protocol#329. With this PR in particular, you added multiple unrelated changes and this significantly increases review time, especially considering that the maintainers also have other priorities.
You could have (and still could) engage with the team and worked out a solution rather than hard forking.
You have me on Discord if you want to message me, lukeeeydev
Hello,
Hard forking CloudburstMC/Protocol is probably not as good of an idea as you think it is. The upstream project has commercial backing and has certain requirements for a reason.
For example, the library supports Java 8 as a minimum because this enables compatibility with the widest array of software. It is still quite common for Java libraries to target Java 8.
I believe you forked this because you were frustrated with the slow review times for PRs such as with your Javadoc PR CloudburstMC/Protocol#329. With this PR in particular, you added multiple unrelated changes and this significantly increases review time, especially considering that the maintainers also have other priorities.
You could have (and still could) engage with the team and worked out a solution rather than hard forking.
You have me on Discord if you want to message me, lukeeeydev