Minetest version numbers

[Sergey]

Minetest version numbers must be natural numbers (positive integers) like Firefox has.

Firefox 49, next is Firefox 50, current version is Firefox 51.

I don't understand the desire of having version number like 0.4.15. WHY? What is zero? Really what is it? Why not one or two? Then what is four? And what is fifteen?

I think it's simple. New version — new number. Period.

[rubenwardy]

Minetest uses a half-arsed version of semvar, with no patches.

4 is the major version, and is incremented every time there is an incompatible or major change
15 is the minor version, and is incremented for every non-major release.

Example:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

0.3.0
0.3.1
0.4.0 - added modding API!
0.4.1 - more features, (should be) still compatible
0.4.2 - more features, (should be) still compatible
0.4.3 - more features, (should be) still compatible
0.4.4 - more features, (should be) still compatible
...
0.4.15


Real semvar would make Minetest's version like 4.15.0, where the 0 is a patch version - it's incremented every time a bug fix release is made that does not add features.

If Minetest does change system, it will be to proper semvar

For more information, see http://semver.org/

[stu]

Minetest uses a half-arsed version of semvar, with no patches.

I actually quite like that to be honest, why does it even matter?

[tinoesroho]

Because pedantic posters get picky when somebody says "I downloaded 4.15"

(We all know they're referring to 0.4.15, but at least one person goes "you mean 0.4.15, edit to change")

[veriaqa]

Then just ignore the pedantic, no biggie.

[Sergey]

Minetest uses a half-arsed version of semvar, with no patches.

4 is the major version, and is incremented every time there is an incompatible or major change
15 is the minor version, and is incremented for every non-major release.

Real semvar would make Minetest's version like 4.15.0, where the 0 is a patch version - it's incremented every time a bug fix release is made that does not add features.

If Minetest does change system, it will be to proper semvar

For more information, see http://semver.org/

In this case, next time when new major version will be released, it should have version 5 — Minetest 5.

After that, Minetest 6, and so on...

[rubenwardy]

Nope, as said it won't change. Even half-arsed semvar is more informative than that.

[Sergey]

By the way, why the game was named Minetest? What do we test?

[rubenwardy]

That's a separate issue. It's a really crappy name - unfortunately no-one can agree on a new one, so it hasn't been changed (yet)

[Sergey]

That's a separate issue

OK
viewtopic.php?f=5&t=16706

[Sergey]

Real semvar would make Minetest's version like 4.15.0, where the 0 is a patch version - it's incremented every time a bug fix release is made that does not add features.

If Minetest does change system, it will be to proper semvar

For more information, see http://semver.org/

So, let new version be 4.17.0.

[sorcerykid]

Is everything about Minetest a complaint?

[Sergey]

Is everything about Minetest a complaint?

Sure, nothing is perfect.

[Wuzzy]

It's very simple:

You have to read the version number as 3 separate integers (positive or 0) and the points are just separators. All three numbers serve as “counters”, and one of them is increased every release.
The first number is the most significant number, the second the second-most significant number. You can use the versions to distinguish which version is older, and which one is newer.

So 0.1.0 is older than 0.2.0. And 0.4.0 is older than 0.4.1. And 0.4.15 is newer than 0.2.16. Easy.

The “4” and the “15” are just two numbers which got incremented every release.

So it has been:
…
0.3.0
0.3.1
0.3.2
…
0.4.0
0.4.1
0.4.2
0.4.3
0.4.4
0.4.5
0.4.6
0.4.7
0.4.8
0.4.9
0.4.10
0.4.11
0.4.12
0.4.13
0.4.14
0.4.15

Easy.

There is no real logic whether to increase the second or the third number. It is supposedly for “large” changes, but this is very subjective. The last time the second number has been increased was with the introduction of the Lua API. When the first or second number is increased, all numbers right from that get reset to 0.

This means, the next version will either be 0.4.16, 0.5.0 or 1.0.0. But it will probably be 0.4.16, and definitely not 1.0.0 (it is too early).

To explain the leading 0: Yes, it actually has a meaning! For almost all software on the planet, a leading 0 in the version number means that a software is not finished. It is either in alpha or beta stage.

This is perfectly true for Minetest: Minetest is in alpha stage, thus it has a leading 0. “Alpha version” means, there are many missing features and it is riddled with bugs. Work in progress.

As soon as Minetest is considered more or less finished, “mature” or “stable” enough, I bet there will be version 1.0.0 far in the future, which will be a major milestone, of course.

So PLEASE do not leave out the leading 0, it is part of the version number. It is annoying me and many developers to no end. Because in future, there might even an ACTUAL version 4.15 (with no leading 0), and then we're confused.


I think users should not dictate how the developers release the software or which version numbers are used. They have only a right to complain if the version numbering is really braindead and causes problems. Minetest's versioning system could be slightly better, but it is FAR from being braindead and it is still perfectly acceptable.

Minetest version numbers must be natural numbers (positive integers) like Firefox has.

No. Firefox' versioning system is absolutely braindead. I often heard from add-on developers that it makes add-on development and especially dependency management a huge pain in the ass. Firefox should have sticked with the previous numbering system. The problem is not so much the version number system but the absolutely crazy practice of increasing the first number for every freaking release for no reason. This makes dependency management for add-on developers very painful.