Poll: Keep or drop 1.7 support?
You do not have permission to vote in this poll.
Keep 1.7
27.78%
5 27.78%
Drop 1.7
72.22%
13 72.22%
Total 18 vote(s) 100%
* You voted for this item. [Show Results]

Drop or keep 1.7 support?
#1
Mojang will start releasing major updates at a faster pace than before. I think we should drop 1.7 support, since it isn't used by many at this point, and it requires more work when adding new features. Additionally, major features have been broken for over a year, such as placing blocks and using items with right-click features.

What do you think?
Reply
Thanks given by:
#2
1.7 is only used for mods nowadays, which Cuberite doesn't support anyway. I say drop it.
Reply
Thanks given by:
#3
I have a more general concern: Multi protocol support is only superficial. Login works, but it's easy to crash things when different version clients are playing together. Old clients are not shielded from alien packets like unfamiliar items. So in reality we only have half-baked multi-protocol support.
Reply
Thanks given by:
#4
Using the Minecraft Launcher, a user can select any version released by Mojang to play on. I've always like that, and it would be nice to be able to do the same with Cuberite. So if anyone ever wanted to host an alpha server for nostalgia or whatever, they could. Just thinking about max client compatibility, when you take options away like drop 1.7 or later drop 1.8, you limit the potential of Cuberite. Just my thoughts, not everyone like to run the latest versions.
Reply
Thanks given by:
#5
You mean we shouldn't drop it, just disable it by default? The thing is, we can't as easy disable 1.8 features.....
Reply
Thanks given by:
#6
Selecting a version in the launcher effectively downloads that old version. The same can be done with Cuberite - you can download the last version supporting the 1.7 protocol. True, we don't have a launcher for that.
Reply
Thanks given by:
#7
There should probably be a list somewhere on the site which lists the last version for every available protocol. Add a notice that older builds will lack new features, but at least they can still be used. This is kind of how Bukkit worked in the past as well, and it worked quite good.
Reply
Thanks given by:
#8
We do have GitHub Releases for the old protocol, but somehow 1.7 was forgotten when it was removed. And it lists other versions too, so it is probably no longer a good candidate.
Reply
Thanks given by:
#9
72aa50f710200832f97a0022dc70c5cd531b6aea is the last commit that supports 1.7, if anyone with permissions wants to add a release to the repository.

1.7 builds:
Linux 64-bit: https://builds.cuberite.org/job/Cuberite...ite.tar.gz
Linux 32-bit: https://builds.cuberite.org/job/Cuberite...ite.tar.gz
Windows 64-bit: https://builds.cuberite.org/job/Cuberite...berite.zip
Windows 32-bit: https://builds.cuberite.org/job/Cuberite...berite.zip
FreeBSD 64-bit: https://builds.cuberite.org/job/Cuberite...ite.tar.gz
Reply
Thanks given by:
#10
Hi, hope this is ok to post here, if anyone else is interested in 1.7.x support I am backporting it to the latest version of Cuberite. The existing code that was removed can be mostly added back without too many difficulties, but there were some new and changed virtual methods I had to modify to get it to build. Then there were game incompatibilities to resolve: not sending the offhand item (45th slot in player inventory) to not crash the 1.7 client, and sending named sound effects with the old names (like "random.chestopen" instead of block.chest.open) instead. However it mostly seems to work after resolving these issues, and I have not seen the block placement issue (#2026), though new items not present in may still be a problem (#2275).

I understand the community voted to remove 1.7, but if anyone wants my version it can be found on my GitHub (same username) under the "restore17" branch, and I welcome feedback (bug reports or fixes) on that repository (issues are enabled).
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)