FOSS gamedev and creative worlds

The processes used in our current software development lifecycle is riddled with problems and clearly resembles an immature development model.

Versioning
Every release after celeron55 passed Minetest off, only the patch version number has been incremented. I suppose the major version number stayed 0 to serve as a reminder that MT is not a finished game.
Minetest is not quite an 'indy' game (nevermind a game) any longer. Instead, as an engine hosting a plethora of games, the goal becomes a moving target with no end in mind, so this sort of pre-alpha nomenclature isn't quite valid any longer.
I'm not sure if the game-to-engine transition was anybody's vision, and surely was not celeron's, but it is what naturally evolved from the inclusion of such a powerful scripting API and people mostly seem to like it.
Nevertheless, the version string is being used incorrectly and we can't indicate a patch release because that's being used as the minor version.

Releasing
The master branch goes into an indefinitely long feature freeze in which only bugfixes or cosmetic changes may be committed. They usually last 1 week but they may be extended based on the whims of a couple people who object. After this period of waiting, several developers relevant to the release process, often the only ones with control over some portion of it, must gather together to follow a set of established guidelines and perform the release. Development then resumes after this.

Maintenance
No patches for a release unless there's something very wrong to prevent it from working.
This results in Minetest hanging in a state perpetual bugginess. Problems that don't get fixed or show up during the feature freeze are left broken until the next release, where there are new bugs.

A Modest Proposal
First, fix the version number fiasco. The next release of Minetest should be 5.0 and with each subsequent release the minor version number is incremented instead of the patch level. The patch level should instead be incremented with each update a version gets after release. I want to clarify that 5.0 was chosen this way: 0.5.0 would probably be a good place to restart at since it's even, and let's be honest, the current version's codebase has little to do with 0.4.3. Then, shift each number to the left one decimal place. Therefore, 5.0.

Let's use a modified version of the FreeBSD release model. Each release will result in a bump of the minor version number. Separate branches will be maintained for each release; bugfixes and worthwhile performance improvements will be continually backported to the previous release.
Feature freezes should involve creating the branch that is to be released, mark it as an -RC version, and simply not push new features to that branch (but, by all means, keep working on upstream master).
And please, let's have the binary building process standardized so that it can be done by any one single person. More dependencies is bad. I want to see builds more often. Because builds will be more common and current, there won't be any stress or failures to deliver when a holiday release is made (when the needed developers probably won't be around)

So to recap, it'd work like this:
5.0.0 is the current version
upstream/master is 5.1-dev
Let's say we fix some sort of big bug that existed in 5.0 - we backport the fix to 5.0 to the "5.0" branch and mark the version 5.0.1. We won't backport the fix to any versions older than that, however.
A release should come, so we create the 5.1 branch and call it 5.1-RC1. The feature freeze is in effect for this branch, but new features can still be added to upstream. Bugfixes should be pushed to both upstream and the release candidate fork. After a week or two (with several builds in between), 5.1 should be released. The patch number gets set to 0 and the version is called 5.1.0.

I don't like the idea of maintaining several branches. This just makes stuff complicated and adds useless workload for core developers to do.
We currently have the situation that basically everyone uses the latest stable version or even the latest dev version. There is no need to maintain older releases by backporting stuff to them.
The feature freeze we currently have is quite good, since it forces everyone to actually find and fix bugs. If we just freeze some branches, then everyone will just continue to add new features in other branches, which renders the freeze useless.
I agree that that the feature freeze takes too long, though. This may be fixed by setting a release date when declaring the freeze and following this plan more strictly. You may say that this was already done the last times, but it wasn't done properly. For instance, I never knew the release date, since it was communicated badly and I only heard rumors from non-dev members of the community once in a while. We need a better system to communicate release plans. I suggest issues on Github, since they integrate easily in our current communication channels and it's easy to use for every dev.

As for the version number I don't care at all. If people think the current system of counting is not good, then I'm fine with a new way of counting.

PilzAdam wrote:The feature freeze we currently have is quite good, since it forces everyone to actually find and fix bugs. If we just freeze some branches, then everyone will just continue to add new features in other branches, which renders the freeze useless.

No, PilzAdam, it's shit. The developers aren't diligently testing every nook and cranny of Minetest during a feature freeze, the users are. Bugs present in a release candidate simply get higher priority when found. As for your argument that maintaining the release branch somehow makes things difficult to the point of unworkable, I don't buy it.

PilzAdam wrote:I suggest issues on Github, since they integrate easily in our current communication channels and it's easy to use for every dev.

-1. I don't use github as a form of communication and it's the same with others too. I view it as a place to hold code and manage issues. Let's do communication on a mailing list or something else.

Even if you keep deleting my posts I think you guys really should discuss and merge the pull requests instead of having an argument about versioning :)

Linuxdirk wrote:Even if you keep deleting my posts I think you guys really should discuss and merge the pull requests instead of having an argument about versioning :)

Why don't you create a new topic about that instead of hijacking this one?
I am not the one deleting your posts by the way, but I agree they are out of place.

hmmmm wrote:… but I agree they are out of place.

Are they? You mentioned “Minetest hanging in a state perpetual bugginess”. A lot of those pull requests eliminate bugs. Wouldn’t it help to merge them before the feature freeze to prevent the buggyness?

hmmmm wrote:Problems that don't get fixed or show up during the feature freeze are left broken until the next release, where there are new bugs.

A feature freeze should only be as long as it needs to eliminate the known bugs of the implemented features added from the latest release up to the date of the feature freeze.

Bugfix releases should be done more often but may need at least two branches.

This mostly seems reasonable. In fact the inability (mainly because the current version numbering doesn't support it, I assume) to backport significant bug fixes and performance improvements to the latest stable is something that I've pondered on for a while now.

Linuxdirk wrote:Are they? You mentioned “Minetest hanging in a state perpetual bugginess”. A lot of those pull requests eliminate bugs. Wouldn’t it help to merge them before the feature freeze to prevent the buggyness?
Bugfix releases should be done more often but may need at least two branches.

We had to add hacky workarounds to a handful of bugs marked as blockers for this release because the people needed simply aren't available. I agree we need to set aside some time for merging pull requests, but it's far from a cure-all like you suggest it is.

I agree with all of this. Also, this will stop me face palming when they say "but it's only in 0.4, Minecraft is in 1.8" as an accuse for bugs and incompleteness.

What about older versions? Will you rename 0.4.x to 4.x on the change log and when discussing it?

As for the branch thing with the feature freeze in one branch, that sounds like a lot of work as you then have to port fixes to upstream from freeze/rc.

I agree that our current versioning scheme is poor.

I do not like the suggested version numbering very much, since “5.0” etc. suggests that Minetest is very finished.

But it is not finished IMO, and I am refering to the engine only!

• A couple parts in the Lua API are still in flux and I am not aware of any stability promise. There is no guarantee at all that future Minetest versions will not break your current mod. Changes happen often to the HUD elements, they tend to break old GUIs and mess around with HUD element positioning (i.e. all the positions of my tutorial formspecs were slightly misplaced after I updated to 0.4.11). Mature engines should have a stable API, an API which is in flux is a sign of not being finished.
• The controls are horrible and inflexible to use for mods. IMO there should be a complete rework here. Confusing and inflexible game controls are nothing you want to see in a mature game engine.
• The main menu is lacking a lot of the cool features which have been added recently, users still have to go into minetest.conf for the cool stuff
• Internationalization is very incomplete, but Minetest forces the system language anyways, unless you set it in minetest.conf, which means you have an ugly English-<YOURLANGUAGEHERE> hybrid. But even the engine has some missing strings. Only the engine is mostly cleanly translatable, mods are not. UTF-8 support is still non-existant. The code for this has been written by xyz about a year ago, it still did not have been merged. And the mods are not translatable in a simple standardized non-hackish way.

Why not going with semantic versioning (http://www.semver.org) instead? It would fit perfectly to Minetest, since its API is now so important.

Basically, semantic versioning works like this (incomplete/rough description):

MAJOR.MINOR.PATCH (i.e. “1.0.0” or “0.5.0” or “0.4.11”)

MAJOR, MINOR and PATCH are all integers, PATCH gets increased for backwards-compatible patches and bugfixes only (!), MINOR gets increased for backwards-compatible changes and MAJOR gets increased for backwards-incompatible changes. Unfinished software where the API is heavily in flux starts at MAJOR number 0 and stays at 0 until the API is more or less stable.

This scheme has the benefit that modders (at least after 1.0.0 has been reached) can immediately see from the version when they should update their mod. Also, it would be versioning scheme that finally makes sense. Our current versioning scheme is pretty unsystematic, it looks like as if the 2nd version number got increased whenever some core dev “felt like it”. :D

As a note to non-developers and others reading this topic and the related "Quality Assurance" topic, these two are strictly moderated. Posts that are offtopic, non-contributory, complaining, "why don't you do X", etc. will be deleted without comment.

These two topics are for serious discussion ONLY. Take any other such talk to another thread.

Thank you.

I think the players would get irritated when the version numbers suddenly jump from 0.4.11 to 5.0.
As Wuzzy already said above - changing the major number means API breaking changes.
I would prefer to jump to 0.5.0 in the next time when UTF-8 has been added to the game.
This zero at the beginning is nothing bad, it just shows: The game did not have any API breaking changes yet (except in the early times when mods were incompatible with newer minetest versions).

Backporting to the latest stable version can be useful but currently, it's not needed except the devs want to release a stable version (almost) every week.

About the -dev patch: Both ways can be correct.
0.4.11-dev -> is not a completed 0.4.11 version, thus in developement
0.4.11-dev -> uses 0.4.11 as base and contains new developement stuff
I personally like the 2nd way.. but this depends on the point of view.

What does it matter if the version number irritates anyone now? It'll only happen once, and people can just get over it. The reasoning behind the 5.0 version number was simple: we're at 0.4.11 now, so if the next version would have been 0.4.12...

0.4.12 --> drop the leading zero as so many users are wont to do anyway --> 4.12 --> bump it to 5.0 to start it at a nice round number.

Add a trailing .1, .2, (thus, 5.0.1, 5.0.2, etc.) whenever a new patch release comes out.

From then on, semantic versioning or something substantially similar.

Using version 5 is totally unrelated to the idea that 0.5.x was supposed to be the "break everything because we eventually need to" concept. That'll be saved for some other version number, maybe version 6.0.

Besides, starting at 5.0 ensures that the fewest possible people confuse future Minetest versions with old 0-prefixed versions that would otherwise have similar numbers (because of their propensity for dropping that leading zero, e.g. 0.2.x somehow being the same as 2.x).

I may not be a core developer, nor a professional in the field, but this topic is of great interest to me as a Computer Science student who wants to make games.

I personally agree with hmmmm: the development process could be better, and he has a great model there. The problem, however, is that the development team isn't large enough to easily maintain a plan like that. At least integrating some parts of it would be good, however.

As far as version numbering goes, I agree that 0.4.x should be done away with. But I also agree with Wuzzy's numbering plan better, although the highest I would use as a number would be 1.5.0. It makes no sense to jump to version 5.0, which indeed implies a greater degree of completion. I'd say either 0.5 or 0.12 would be a good place to start. And to those comparing version with Minecraft: tell those people to compare with the Pocket Edition, which currently sits at 0.10.4.

As far as completion of the API goes, there also is work to be done with registration tables, and the need for more of them to be exposed to Lua. And if you're looking for that magic compatibility-breaking feature, consider a reworking of node definitions, particularly as regards node textures. The API aims to make the game as flexible as possible, yet countless mod ideas get stopped short by the lack of texture changing on the fly.

I noticed that it was claimed that backporting bugfixes was unnecessary, since people either use stable or current dev. In reply, I will simply say that is BS. Sure, most of the forum goers fall under that category, but also many new users only wish to play the game with as few bugs as possible, and are shy of trying the (usually) guaranteed buggy dev releases. But if that only means they have a false sense of security... So bugfix-backporting is a must.

Like some others I do not think the next version should be 1.0.0 or 5.0.0 but rather 0.5.0 and the roadmap adjusted accordingly with a lot of stuff sheduled for 0.5.0 being reassigned for version 1.0.0

The idea would be to jump to version 0.5.0 with the next version and from there on quickly pace to 1.0.0 mostly using the middle digit and maybe skipping some, so that hopefully within some months the version 1.0.0 is reached and from there on the system as hmmmm described or explained in the semantic versioning link should be used.

I could imagine this would be less confusing than simply shifting the numbers to the left.

twoelk wrote:Like some others I do not think the next version should be 1.0.0 or 5.0.0 but rather 0.5.0 and the roadmap adjusted accordingly with a lot of stuff sheduled for 0.5.0 being reassigned for version 1.0.0

Exactly. Minetest developers should not raise version numbers like browser developers do since Google Chrome was first released.

Actually Wuzzy explained it very well how version numbers should be assigned.

And to those comparing version with Minecraft: tell those people to compare with the Pocket Edition, which currently sits at 0.10.4.

Sigh. People should not comparing version numbers of different softwares at all. It just does not make sense. Also, a leading 0 does not always mean the software is considered unfinished, because numbering schemes vary greatly between software.

As Wuzzy already said above - changing the major number means API breaking changes.

Ummm, not so fast! There is no versioning standard on which ALL software in the world agrees upon. There is not even a widely used one.

Also, your assertion is also wrong if you were referring to Semantic Versioning. The MAJOR number 0 has a special meaning which is used for initial development (rule 4), when the API is still very unstable and changes a lot, so you do not have to increase the major number all the time before the project even really started.

Please read the http://www.semver.org if you want to know what this is about.

About the -dev patch: Both ways can be correct.
0.4.11-dev -> is not a completed 0.4.11 version, thus in developement
0.4.11-dev -> uses 0.4.11 as base and contains new developement stuff
I personally like the 2nd way.. but this depends on the point of view.

This is easy to decide when one uses Semantic Versioning. It has been well-defined under Semantic Versioning. In Semantic Versioning, 0.4.11-dev comes before 0.4.11 (rule 9).

I would prefer to jump to 0.5.0 in the next time when UTF-8 has been added to the game.

This is quite arbitrary. You might use any other big feature as well. And, frankly, this is exactlyy the versioning model we have right now. Increasing the version numbers on more-or-less arbitrary criteria. So not an improvement.

What does it matter if the version number irritates anyone now? It'll only happen once, and people can just get over it. The reasoning behind the 5.0 version number was simple: we're at 0.4.11 now, so if the next version would have been 0.4.12...

0.4.12 --> drop the leading zero as so many users are wont to do anyway --> 4.12 --> bump it to 5.0 to start it at a nice round number.

Add a trailing .1, .2, (thus, 5.0.1, 5.0.2, etc.) whenever a new patch release comes out.

From then on, semantic versioning or something substantially similar.

But if you want to use Semantic Versioning, please use it correctly and don't forget to read the document I linked to. :)
http://www.semver.org
If not, please share the other versioning scheme you have in mind.

5.0 would be invalid under Semantic Versioning, it should be 5.0.0. (But 1.0.0 would be more elegant, as this is defined as the “release which defines the public API”, but I guess that is just a matter of taste; also, SemVer is not so strict here.)
Also note that if you use Semantic Versioning, you MUST bump the major number for every compability-breaking change as soon as your major release is greater than or equal to 1. Even if just formspecs are misplaced again, this breaks backwards-compability with Lua scripts and thus you MUST bump the major version number. Unless you do not want to use Semantic Versioning, of course, then you are free as a bird. ;-)
The rationale behind this rule is that developers are hopefully more careful when they are about to break backwards-compability. ;-)

I do not care that much about wheather the next version is 0.5.0 or 5.0.0 or 1.0.0 or whatever, I care much more about which system is used. (I would personally prefer the first, but maybe you could argue that Minetest is indeed complete and has a more or less stable API.)

Obviuosly I prefer SemVer over the current system which is not really systematic. ;-)

But if someone can present me a better model, I am open to that.

hmmmm your proposal sounds good to me.
I would prefer 5.0.0 to 1.0.0 because 1.0.0 implies to the public a finished game released, that sort of 'baggage' makes me uncomfortable and is unsuitable. 5.0.0 is much more vague and also has continuity from where we are now at 0.4.x.

I give my applause to Wuzzy. Minetest should just choose the SemVer idea because it is organized and it seems standard. This is more of who is looking at Minetest rather than what we think sounds good. If people look at it and see no beginning zeros, IMO they will think that see it as a game that progresses quickly with many patches and such at a much quicker rate than we really are going at. I think that SemVer is so much cleaner and is regular to the outside eye. Of course, there is the fact that people don't really want to try an unfinished game, but it is better than inflating Minetest to ten times the size it seems. If you don't really understand this post, I don't blame you (I wrote this when I was half awake, but I have been watching the topic). if you disagree, then that is fine.

philipbenr, Minetest doesn't use SemVer at the moment. It is more like this:

Pointless.Major.Minor

rubenwardy wrote:Pointless.Major.Minor

Feels more like "Pointless0.Pointless4.Major" right now with Minor beeing skipped entirely or relating to a date or particular commit.

As far as versioning goes, this is of course very chaotic. On the other hand, the game as such works fine, and the best way usually is to compile the latest git version and enjoy a game that works very well most of the time and may only have a few problems due to its latest commits now and then.

I want the version number (whichever one) to be increased when:
1. protocol changes and client/server start having difficulties communicating with each other
2. large new features get added that make a huge diffrence in how the player experiences the game
3. major changes to the lua api happen
4. the devs feel the need

Happily, 1.) happens rarely. Recent versions can still talk to Redcrabs server with some tweaking, which runs a version that is close to 2 years old. Still, the tweaking may be too much for inexperienced users, so there has to be a new version when this happens.
2.) may not even be obvious for the developers. It may even be a rather minor change on the code side, resulting in i.e. hugely improved graphics or speed, that may make a new version a good idea so that players *notice* that it's worth updating.
In a way, 3.) is the same as 2.), just aiming at modders instead of players alone.
4.) are such cases when code restructuring or other changes may warrant a cut/mark of the time when those changes happened

Right now, new versions seem to be released more or less whenever enough has accumulated.

Jumping to 5.0.0 *feels* a bit much. IMHO the major number should only be changed when something very drastic changed. It feels odd to have i.e. Firefox releasing a new version with an even higher number so often. On the other hand, many open source programs never get another number than 0. as their first number, even though they've more than matured, work excellent and got a lot of useful features. It's a psychological issue and confusing that there are so many diffrent versions of versions out there.

Something like Pointless0or1.major.minor.commit_nr might represent the current process. The first number would only change whenever there's a really drastic change, while the second one would represent what now switched from 10 to 11, the third would be increased from time to time with bigger changes/enough changes accumulating, and the fourth would just count the amount of commits since the last increase of the third number.

In the end, please use whatever appears to be convenient and acceptable to all devs. And please also use the version number as an indicator for players showing them when it's a good time to update.

I personally prefer PI versioning.

3
3.1
3.14
3.141
3.1415
...

1) Thank you Ruben. I corrected two things in my posts. OT: I was thinking about SigFigs, which I had been working on yesterday. I wrote trailing zeros instead of beginning zeros. And I did know that MT didn't use SemVer. I looked at the links Wuzzy posted. I just wrote it wrong.

2) I agree with Sokomine there. It just *feels* a bit too much. I just feel that the drop of the zero is too much.

would R-*number of release* work too? ie R23,R24

CWz wrote:would R-*number of release* work too? ie R23,R24

Anything would work. You could even use 0.4.potato, as long as it is unique and identifiable.

But the Semantic Versioning thing described and linked a few times in this thread is the most reasonable and useful approach because it’s based on audit-proof and testable facts instead of being an arbitrary number.

Versioning
This has been discussed before and everyone agrees to it (AFAIK), there's just some controversy about exactly how the new versioning should work. I think that the starting version for this should be 0.5.0 if there's no major compatibility-breaking change from the 0.4 series since that's how the versions are supposed to work according to SemVer. I also see the Minetest API as fairly experimental still because there are a number of big warts that should be fixed (formspecs, global mod namespaces, ...).

It me "x.y.z-dev is x.y.z plus new stuff" seems more intuitive than "x.y.z-dev is what will become x.y.z". It also means that you can add a big change and decide that the next release should be a major increment instead of a minor one or vice-versa. Semver point 9 refers to things like -alpha, which obviously should come before the non-postfixed version.

Core team
<semi-offtopic>
The core team is fairly small now, and I think that we could progress much faster with more developers since PRs could be agreed to faster and there would be more people helping. Our team would be great if everyone was always around and lived in the same area, but the fact is that we all have a lot of other things to do and are around at different times. It's hard to find good developers though. They have to know C++ and Lua, they have to be around for a while, they have to be trusted, etc. We might be able to improve this by having different classes of core contributors, eg, engine devs, game devs, documenters, and translators. That way you wouldn't need as many skills to help directly with the core elements.
</semi-offtopic>

Branching
I think a separate branch for releases while development continues on the master branch would be good. This allows for semi-long (1-2 week) feature freezes, minimizing bugs, while not stalling development during that time.

Releasing
Releasing definitely needs to be easier. You need to make Windows MinGW, Windows MSVC, and Android builds, which currently depend on three different people (if I'm not mistaken) which are located in different areas and have different levels of activity.

Maintenance
Back-porting significant bug fixes and improvements as a patch release is a good idea too (IMO). This is limited by versioning though of course.

ShadowNinja wrote:It me "x.y.z-dev is x.y.z plus new stuff" seems more intuitive than "x.y.z-dev is what will become x.y.z".

Yep :) That’s the only downside of strictly following SemVer rules.

ShadowNinja wrote:Our team would be great if everyone was always around and lived in the same area, […]

It’s 2015. Is “not living in the same area” still an issue? I mean, there are mailing lists, the Git repository, the forums you could call eachother with no costs via Mumble, Reamspeak or, for the worst: even Skype would work for that. Call yourself oldschool, but there is just absolutely no need for physical appearance when working in a software development team when having an online version and revision control system. :)

Only time zones could be an issue when you want to call each other or want to have an online discussion in a mailing list or the IRC.

ShadowNinja wrote:You need to make Windows MinGW, Windows MSVC, and Android builds, which currently depend on three different people (if I'm not mistaken) which are located in different areas and have different levels of activity.

What about setting up an automated build server?

ShadowNinja wrote:Back-porting significant bug fixes and improvements as a patch release is a good idea too (IMO). This is limited by versioning though of course.

Limited by current versioning which seems to be only an arbitrary number instead versioning based on logic. You can backport bugfixes to lower minor versions without breaking the SemVer rules. And if you backport everything without breaking anything just do a +0.0.1 on the current version number – even if it’s fancy stuff you think about it could deserve a +0.1.0 instead :)

Linuxdirk wrote:

ShadowNinja wrote:It me "x.y.z-dev is x.y.z plus new stuff" seems more intuitive than "x.y.z-dev is what will become x.y.z".

Yep :) That’s the only downside of strictly following SemVer rules.

Nobody said that you have to append “-dev”. You could append any arbitrary string that seems reasonable to you (and only contains allowed chars, of course).

But please do not fall into the trap to use, let's say, “1.0.0-dev” as a shorthand for any version which comes before (or after, if you wish, this does not matter for this paragraph) 1.0.0. In other words, one version should only map to one Git commit. But if “0.4.12-dev” is not really a version at all, because, it can basically refer to any commit between 0.4.11 and 0.4.12, that would be bad. It would be weird even under the current system.

Currently, Minetest shows something like “Minetest 0.4.11-45-g3c3887b” for dev versions in the left upper corner and “Minetest 0.4.11-dev” in the Credits screen. The first one does not go well together with SemVer and the second one is just misleading, because I know that 0.4.11-dev does not refer to a specific commit, so it is not a “real” version number. Bad enough that Minetest shows two different strings which look like version numbers.

So I propose to drop this “-dev” convention and the other convention altogether. Instead, in any developer version which have not been assigned an unique version number (like “1.0.0”), Minetest should display the Git commit ID instead.
Maybe instead of “Minetest 0.4.10-dev”, write “Minetest developing version (Commit ID: abcdef123456…)” or something like that, so it should be clear that this is not a stable version and does not even have a version number.
So those “developer versions” which may change rapidly anyways simply would not have a version number, unless someone explicitly assigned one. I do not know how well this thing could be automated. I think people should post the commit ID (or at least the first few characters of it) in bug reports anyways, and being able to see it in Minetest directly makes it slightly more convenient. Bug reports which report a bug in “0.4.12-dev” (under the current system) are not as helpful as a bug report for commit ID “abcdef123456…”.

But I recognize there is a clear need for pre-releases.

Maybe simply using a more “speaking” suffix would be sufficient to work around this. “-dev” would not be an unreasonable loss IMO, and I prefer “following the SemVer standard” over “almost following the SemVer standard”, obviously. :D

What about “-pre”. I.e. “1.0.0-pre” would be a version before 1.0.0 by the rules and intuitively, too. “pre” sounds like “before”.

And if you noticed you want to do another pre-release, simply append a dot and a number like this:

1.0.0-pre.2

Increment the number as often as you need it:
“0.9.0” → “1.0.0-pre” → “1.0.0-pre.2” → “1.0.0-pre.3” → “1.0.0” → “1.0.1” → and so on …

But again, it is important that “1.0.0-pre”, once defined, should never ever be used again to refer to another commit, otherwise it just becomes a meaningless “range of commits version number” like “0.4.11-dev”.

Or maybe you want to be more expressive and go with “-alpha” (lots of unfixed bugs, proof of concept, early testing), “-beta” (for testers) and “-rc” (fine-tuning and polishing stuff, should only have minor issues left), and append numbers like in the previous example (“2.0.0-beta”, “2.0.0-beta.2”, etc.).

These are only examples, you have to decide for yourself what pre-release suffixes to use.

But I hope I made clear that, depending on the string, the SemVer meaning of “1.0.0-somestring” can be intuitively as well, you just have to use a string which works best for you. :)

One quick suggestion that follows shadowninja's semi-offtopic section: How about the devs be more active on the forums? Also, the Partly official engine development section is "For people working on the C++ code." I wish I could see more developers posting there. As for you, hmmm, thanks for posting here in the forums more. It is really nice to know there is somebody out there that is actually working on this.

I don't really care about version numbering, as long as vanilla minetest doesn't corrupt worlds. We should talk more about the release cycle and branch management, then version numbers.

What i saw especially with the 0.4.11 release was the uncertainty of the release date and different release stages (dev, freeze, testing, rc, release).

I just took a look at the release history (0.4.3 - 0.4.11) and the time between releases is 6 month max and 1 month min. The average is about 3 months (5-6-2-5-2-1-3-4).

So it might be smart to change to a regular release cycle of 3 or 4 month. So everybody knows when a version will be released and everybody can plan accordingly.