![]() ![]() ![]() ![]() Recently I started using Final Minetest, so now I can focus on improvements that I had planned starting about three years ago, but that I hadn’t implemented since I was instead dealing with the upstream issues.Īs far as Minetest 5.0’s system of implementing community improvements, the devs usually go through a long process of closed discussions (:edit: or effectively closed discussions since laymen usually don’t understand IRC nor monitor the minetest dev IRC channel, and since the IRC points aren’t elucidated in the issue thread but do lead to closing the issue thread, and often overrule the majority of user feedback), sometimes taking months or years, even for minetest_game (which is a minimal collection of mods and not a full game though included and documented as such) then make or reject changes without notifying the community nor contributor, nor providing technical descriptions of the changes. I spent the majority of my limited server maintenance time fixing other people’s mods (usually broken by ’s API changes on GitHub) and creating software to maintain the server, such as mass inventory editing and mass mod updating. I chose to use the git version since I am a developer and the server was not public, similar to why a mechanic may own a “fixer-upper.” However, I got in over my head and eventually had to be careful about updates and backups. As a contributor and server owner during this entire period (also going back to 0.4.13-git on the same server), I concur with that (at least since 0.5 on /minetest/minetest) is in technically-defined “fork” status (regardless of lack of “administrative,” or stated, fork status).įor over two years or so I ran a Minetest server owned by a high school, using the git (GitHub) version ’s Minetest 5.0.0 (previously called 0.5). The current release, 5.0.1, is administratively marked stable but doesn’t even have a recipe for stairs. They even backported some of the breaking changes into 0.4.17 (and possibly earlier “stable” versions, see below). I can vouch for the fact that the 5.0.0 (originally 0.5) branch introduced many breaking changes, regardless of how administratively labels it. Expectedly, each site explains the issue differently. So somehow it got out and both claim to be the stable branch of Minetest, similar to the FFmpeg vs. I'd like to see the project return to a state allowing sever owners to do that.Įdit: and before someone tells me that 0.4.17 doesn't exist yet, I should point out that I have a client right in front of me that reports 0.4.17 as its version. That's what I used to do, server-side, until the breaking changes started comming in. This was the state (with a few exceptions I believe) before 0.5.0 was being worked on. What I want to see happen is for the network protocol to become stable again during further development after the official release, so that servers (including mine) can use the latest dev versions as much as possible. ![]() I understand the network breakage is necessary for 0.5.0 and I'm not really troubled by it yet. All my players are still on 0.4.16 or 0.4.17. There are a lot of server-side performance enhancements and other good stuff in the dev versions beyond the last stable release, but I cannot upgraded my server to use them because of network incompatibility. Thus, if the latest version on Github changes the network layer then a server cannot upgrade to it immediately without cutting players off, and instead must wait for players to update first, which can take a long time.įor a real example, take my own server. Most players (99% probably) don't have the ability to update their client at will. So i guess i should decide what mapgen bugfixes should be applied. We can't just do a point release because a lot of compatibility breakage has already happened and started immediately after 0.4.16 was released, all we can do is take 0.4.16 stable and add bugfix PRs to it. Also, some nasty forked Android apps may not update to 0.5.0 so we have a rare chance now to encourage mobile players to switch to the official app (which hopefully will be worked on and improved before 0.5.0 is released), there will be more encouragement if servers move to 0.5.0 earlier than later.įor 0.4.17 let's not put too much work into it, just 0.4.16 stable plus a few major bufixes, no features. For example enforcing CSM restrictions (flavours) is only possible in 0.5.0. However i do not want to encourage people to stay on 0.4 as there are good reasons to encourage people to move to 0.5.0 as soon as possible. The idea of 0.4.17 was to provide a final 0.4 version for those who want to stay with 0.4 for a while. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |