Release Engineering

[rubenwardy]

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.

We're not Microsoft. We release versions when they're ready and when it makes sense. Versions numbers don't matter that much, anyway, if you play the latest dev.

[Linuxdirk]

… if you play the latest dev.

Exactly. If you play the latest dev.\
But since the majority of users aren’t developers but normal users they care. A reliable versioning scheme and continuous bugfix releases until the next feature release is something most users expect because they know it from other software.

[rubenwardy]

Err, what? You don't need to be a developer to play the latest version. It's just a version which has the latest features, which may be modified before the version is released.

[Wuzzy]

It's just a version which has the latest features, which may be modified before the version is released.

It is also the version which has the latest bugs. ;-)
Not everyone wants to be an alpha, beta or whatever tester, some people just want to play.

continuous bugfix releases until the next feature release is something most users expect because they know it from other software.

This is a good and important point here. Imagine this: After X months, a release happens, then an annoying but easy to fix bug appears a week after the release. It also got fixed pretty quickly, but now all users have to wait until the next release to get those bugfixes. Using the bleeding edge is not an option precisely because it probably has a lot of other bugs and untested weirdnesses, so you would trade one fixed bug with a full sack of new bugs.

Let's suppose 0.5.0 is released.
One week later the annoying bug is noticed. Shortly after it is fixed in bleeding edge.
Now John Doe could use bleeding edge, but it may have accumulated other annoying bugs in the meanwhile. And 0.6.0 would take a long time to release.
The solution would be to backport all bugfixes or at least all important ones to the 0.5.0 branch and release it as 0.5.1, 0.5.2, and so on. Important: The bugfix release 0.5.1 should be based on 0.5.0 code and NOT on bleeding edge. This way, it is possible to make bugfix releases even if bleeding edge has advanced a lot.

This simple process should (hopefully) ensure that John Doe can always have a relatively stable Minetest version.

[lightonflux]

This is a good and important point here. Imagine this: After X months, a release happens, then an annoying but easy to fix bug appears a week after the release.

But for something like that we don't need to plan regular bug fix releases. If something like that really happens it can be done on an case to case basis we don't need a rule set for (yet) theoretical cases.

[Zeno]

Let's just set a date and release 1.0.0 and from that point use semantic version numbers. Then at least there can be a stable branch, patches for critical bugs backported, and the version number actually means something.

As for regular releases on a schedule? I don't think that's very realistic at the moment (for a variety of reasons).

[afflatus]

If all devs are agreed that the next version is stable enough then release as 1.0.0
else 0.5.0 with a roadmap to stable.
I think SemVer makes the most sense to most people, github and distributions.

Jumping to 5.0.0 when there has never been a 1.0.0 will confuse people.

[rubenwardy]

You could release a news article saying that the 0. is going to be discarded. From there you use semantic versioning. In a rather Ministry of Truth way, you could refer to older versions as say 4.11, 4.10, 4.9

However this may not make sense as the 1.0 version shouldn't be the official public API.

[Linuxdirk]

… and I still think that raising the major version by +5 by shifting the separator to the right makes no sense at all :)

I prefer what afflatus says. Change to 1.0.0 with the next “feels stable enough” release and use SemVer from that point on.

[ShadowNinja]

Change to 1.0.0 with the next “feels stable enough” release and use SemVer from that point on.

Minetest isn't going to "feel stable enough" for a while. We can switch to SemVer now,without any version jumps or other changes. Just continue with 0.5, 0.6, etc. This doesn't involve any version jumps at all and is minimally confusing.

[Linuxdirk]

We can switch to SemVer now,without any version jumps or other changes. Just continue with 0.5, 0.6, etc. This doesn't involve any version jumps at all and is minimally confusing.

Sounds very okay to me! :D