[Suggestion] Remove Unnecessary ancient version Support
Closed this issue · 8 comments
Hey, I have been using BigDoors for quite a while now and me and my players love it, but I just noticed on the Spigot page that it Supports 1.11 o 1.19, which is just super unnecessary, as some of those versions are literally not played anymore...
You can see on Spigot's Bstats or Paper's Bstats that versions like 1.11, 1.13 and 1.14 are literally not played anymore and versions such as 1.12 and 1.15 are barely played anymore...
Note that Support from Mojang, Spigot or Paper for these versions has also been long gone...
So you could optimize/modernize BigDoors code a bit and make it easier to maintain if you remove the support for these ancient MC versions that aren't even played anymore (So make the plugin 1.16.5+ only) (If you still want to support the about 8% of Servers that for some weird reason are still on 1.16...best would probably be 1.18.2+)
This would also probably remove the need for XSeries and thus also quite significantly reduce compile time and jar size...
Edit: or consider doing it like UltraCosmetics does it, support 1.12.2 and 1.16.5+, if your 1.12 playerbase is too big to just remove yet :)
Please tell me what you think about this 😅
Hey, thanks for your message!
Supporting the older versions is not really holding back the development of v1 currently. If you take a look at the recent history of the 1.11 module, you can see that's it's been almost entirely version bumps for the last year or so. In fact, I can't even remember when I last had to change anything for 1.11. Once a module has been added to support a new version of MC, I generally don't have to go back to make any changes to it.
So even though those versions aren't played anymore, it'd take more work to remove support for those versions than to keep it in. As such, I'd prefer to keep the support in, even if there are only 3 servers using BigDoors on MC 1.11 right now.
All work to optimize/modernize/improve the current code is going into v2 (current master branch); v1 is basically on life-support at this point, so I don't really worry about improving the current v1 code too much, as long as it doesn't interfere with required updates/fixes.
Even if dropping support for older versions of MC, XSeries would still be quite useful for easily accessing materials in newer versions. Also, only XMaterial is included, so this adds less than 100kb to the final jar. And lastly, compilation only takes about 7 seconds, which is already pretty fast, especially compared to v2 which can take several minutes if you include all analysis tools and whatnot (and v2 only supports a single version of MC!)
Oh, I didn't even know "v2" was a thing...
V2 is not released yet, or am I confusing something? (The current version on Spigot is v1 right?)
If so, yeah, then it makes sense not putting much work into v1 anymore...and if v2 only supports 1 MC version anyway, then this suggestion here is basically already implemented 😅
Thanks for your quick reply btw :)
v2 is a project I've been working on for a few years now, which is much, much longer than I'd expected, and it's still not in a usable state. As such, it also hasn't been released yet, and any ETA I can give you is probably going to be wildly inaccurate.
However, I am still making progress on it; I got commands working again a few months ago, so I could finally test it out in-game again after years of only being able to test it programmatically.
The way v2 is set up, it'll be just as easy to support multiple versions of MC as it is in v1. The reason it currently only supports a single version is that supporting a single version means less work when I change stuff. When v2 gets closer to release, I'll add support for other versions as well. Considering the only supported version is MC 1.15 (which was the newest version when I decided to drop all other versions for ease of development), I'll have to update it at some point anyway ;)
Having said all that, however, support for older versions of MC will be different in v2, as I plan to stay up-to-date with Java versions for v2. It is currently built with Java 18 and I'll move to 19 when it's released etc. This means that newer versions of BigDoors v2 will not support older versions of Spigot, and Paper (and forks) only when -DPaper.IgnoreJavaVersion=true is provided.
So because v2 will need the newest java versions to run properly, it will officially only support "modern" MC versions?
Sounds perfect :)
Btw, what changes/improvements does v2 have? (Why does it exist?)
Sounds interesting if you have been working on it for that long 😁(MC 1.15 is now over 2.5yrs old 😅)
When I started working on this plugin, I didn't have any intention of releasing it. I was just curious to see if I could find a way to animate blocks and maybe use them to make bigger doors for a castle I was building. By the time I had a working proof-of-concept, I lost the motivation to continue working on it (I very rarely finish anything I start 😅). However, I thought it was a pretty interesting concept and couldn't find any existing plugins like it, so I decided to release it anyway and "rewrite it soon".
Instead of rewriting v1 "soon", I ended up piling more and more stuff on top of the old, hacked-together proof-of-concept code. This ultimately made it an absolute nightmare to work with. It has a lot of duplicated and/or tangled code all over the place, resulting in a house of cards where making a tiny change here causes all kinds of issues there.
The reason for v2 to exist therefore is primarily to rewrite everything and get a fresh new codebase that's easier to work with and expand upon in the future. One of the reasons it's taking so long is that I keep rewriting stuff over and over and because of massive feature creep... And another reason is that I really struggle to find enough time to work on it ;)
Other than just being nicer to work on for me, some of the features in v2 I'm excited about are:
- It is now much easier to add new door types. Also for external developers (they are loaded as separate jars; "Extensions").
- Drawbridges and BigDoors now allow 3d regions and arbitrary rotation points.
- It is generally nicer to use for users (better command system, blocks are highlighted when they are in the way and preventing a door from being toggled).
- The new types (flags, windmills, etc).
There are also a lot of other changes/improvements (I've gone through hundreds of items on my lists; some big, some small), but those are the ones I'm most excited about at the moment.
Damn, that all really sounds nice...now I'm kinda excited to see BigDoors V2 😅
Do you have any kind of very rough ETA estimate? (About how close is it to a "stable enough" build to test?)
Heh, well... I want to say "some time this year", but I said that last year as well, the year before that, and maybe even the year before that. So at this point, I've mostly given up on giving out ETAs, as they have always proven to be wildly inaccurate.
However, I do feel like it's going in the right direction now. After spending a while breaking everything in the process of rewriting it, I've now moved on to a phase where I'm mostly fixing/finishing things. Most of the 'big-ticket' items have been crossed off the list and it's down to more minor things and polish now.
Alright 😅
When you have a "stable enough" and need help testing, I can help you :)