Man, I came across this topic and it was impossible to not laugh near the end. Seriously, for me, it's just a number switch. C'mon, even calling the previous versions with that zero at the start, it would take years to be used (to change by one!), so that zero cannot be more useless than it is right now. (O_o)And being SemVer or not, it's still a version number, officially or not. Call it by a codename if you want :')(Minetest DatPreciousZero Version, (5.0.0))But it can really bring a bit of confusion, it would be good if a big announcement around this subject was made, maybe in the website (and also in the forum).

Also, I have a question.Why mobs aren't native in Minetest? I think that 5.1.0 (corrected by v-rob ( >u0)) would be a nice opportunity to introduce mobs as native features. Playing MTG as survival, offline and without mobs, makes swords and armor pretty pointless...I tried mods for mobs (mob engine, nssm, and even TenPlus1's Mobs Redo which is very good!), but relying in an interpreted language (such as Lua) to deal with objects which require constant processing doesn't seem to be a good idea...

Last edited by Nutty8 on Mon Jul 09, 2018 16:39, edited 1 time in total.

Nutty8 wrote:I think that 0.5.1 would be a nice opportunity to introduce mobs as native features.

Having a formspec replacement and a better networking code would be nice too - oh and please a native realms API. Would be lovely. What works in commercial projects with TODOs and deadlines doesn't work out that well in open-source projects like Minetest. We're happy to see new contributors so that the project goes onward faster.

All that talking about version numbers, and you goofed it up right afterwords :-P

Oh man, I was just so hyped by the news of a major release four or five months agoAnd only discovered before yesterday that the number changed :')I went everywhere speaking "OMG! 0.5.0 is coming!"Force of habit ¯\_(ツ)_/¯In the end what matters is that it's on the road (crying of happiness).

Nutty8 wrote:I think that 0.5.1 would be a nice opportunity to introduce mobs as native features.

Having a formspec replacement and a better networking code would be nice too - oh and please a native realms API. Would be lovely. What works in commercial projects with TODOs and deadlines doesn't work out that well in open-source projects like Minetest. We're happy to see new contributors so that the project goes onward faster.

I think the same about network (mainly after playing OpenTTD online) and formspec.Also,What can I do to be a Minetest (Game or not) developer?EDIT:(My first programming language was C++, I also studied C in high's school integrated technical lessons and college (in addition to Python), but I'm very bad at graphical interfaces and using other libraries except for the standard ones (because only made console applications).) i'm reading the development wiki. And about TODOs and deadlines, I know that the work is totally based in passion, but such features cannot be implemented individually by a developer at own rhythm?

This is breaking update. And so updates are usually developed for a long time. Very long development also may mean the update will be massive and it will contain multiplicity of changes, bugfixes and content. That`s why be patient! I hope the devs will release it in 1 or 2 months.

First of all, getting familiar with the core structure. The wiki provides some help but for the other parts you'll have to look into the source and follow the function call paths.Afterwards there are 700-800 issues on GitHub, whereas some might only be a few changed lines to implement or fix (provided that the right code location is known). The graphical interface is just one part of many, so that isn't a problem.See also: https://github.com/minetest/minetest/bl ... IBUTING.md

(Not really an) EDIT: C++ is the main language of Minetest aside the Lua code in builtin, so that works out perfectly. Indeed are most of the TODOs big projects which require much planning so that the pull requests stay reviewable (5000 new lines are hard to review btw). It is however possible to break up a bigger project into smaller portions: code refactors, API implementation + docs, final tidy and optimizations (+ bugfixes?).

First of all, getting familiar with the core structure. The wiki provides some help but for the other parts you'll have to look into the source and follow the function call paths.Afterwards there are 700-800 issues on GitHub, whereas some might only be a few changed lines to implement or fix (provided that the right code location is known). The graphical interface is just one part of many, so that isn't a problem.See also: https://github.com/minetest/minetest/bl ... IBUTING.md

(Not really an) EDIT: C++ is the main language of Minetest aside the Lua code in builtin, so that works out perfectly. Indeed are most of the TODOs big projects which require much planning so that the pull requests stay reviewable (5000 new lines are hard to review btw). It is however possible to break up a bigger project into smaller portions: code refactors, API implementation + docs, final tidy and optimizations (+ bugfixes?).

same as Krock wrote.i also learn C++ at school for over 20 years and I learn every day more and more about minetest.