Closed heisluft closed 5 years ago
We already make tags for different MC versions, see here: https://glowstone.net/news/7. The minor version (x.x.1) gets bumped up by 1 if we make a protocol change in the middle of a new release.
I'm against supporting previous versions with different branches, as it exponentially increases the amount of work we have to do. We can't even maintain a stable LTS release, which we have mandated in the version spec.
People who want to be compatible with previous versions can use ProtocolSupport and it's up to them to maintain plugins or patches that provide the specific behavior they want. 1.8 combat, for example, is a feature, just like any other additional feature that you would want to add using additional plugins. It's not our obligation to provide these features for server owners if they want them.
My other main open-source project is a Java library with JDK 7 and 8 branches, so I know that maintaining half a dozen or so versions isn't realistic, as @mastercoms has said. Especially when our one version is months behind Mojang.
Thank you for your clarifying statements :D
The Idea is to backport GlowStone as soon as it is feature complete for either versions. This would require 1.x.y branches to be made for each 1.x mc version, respectively. I know that sounds like a whole bunch of work, but especially the 1.8 Community is still quite strong (It's a PITA that MC versions have no real EOL Dates).
This of course aims to be postponed as long as it is necessary (as it obviously does not make sense to backport incomplete versions. When the descision is made to do this further things could be discussed as soon as it is reqiered.
Any discussion, suggestion or information concerning the plans regarding this issue is highly appreciated.
Cheers