The team has been communicative and helpful toward server owners or users seeking to preserve worlds or builds, and toward me as a contributor. Another reason for the difficulty was the high number of bugs in the successive commits. The two-year process was difficult primarily because the team technically forked but did not document the changes nor restrict them to the 0.5-5.0.0 branch. even had concerns with Minetest 0.4.16 (not just 0.4.17 as discussed above), so according to discussions with me, they started on 0.4.15 then painstakingly implemented the later commits, manually circumventing the bugs and compatibility breakages. This process was the initial concern that led to the split according to my conversations with developers. The breaking changes and treatment of contributors who aren’t “insiders” has surely prevented Minetest from reaching critical mass following a surge in popularity that occurred around the release of Minetest 0.4.12 or earlier. A similar discussion occurred on my bones pull request, where the maintainers required that I remove a configuration option, enable_ in names of boolean variables, complete sentences, periods at the end of sentences, complete sentences, active voice, and verb tense consistency. This deletion occurred during an endless discussion over line wrapping preferences in my minetestmapper.py pull request, in which I even conformed their code to PEP8, trying to fulfill their many prerequisites for the minor pull request (which initially affected only new console i/o and missing detection of colors.txt). While I was using Minetest 5.0, my live map system I programmed in PHP and JavaScript from scratch eventually stopped working around when deleted Python minetestmapper from their repo without notice and without an explanation of the engine changes that broke it (I found out recently that my python fork and hence PHP code are salvageable using Final Minetest, or a recent version of the binary minetestmapper fixed in late 2018, a year after I gave up on it). They often delete or change old Wiki articles completely without linking to an explanation of the changes. I don’t believe this is an appropriate methodology for a community project, especially one that insists that even minor contributors do most of the work themselves, including changes that the core developers request. 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. and both claim to be the stable branch of Minetest, similar to the FFmpeg vs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |