Switch to SemVer

[Iniquitatis]

I've been following this project for a long time, and I saw one bad tendency, presented in many aspects: retrograde development model.
I thought, MT is using Semantic Versioning? Maybe, I'm wrong, but let's look in Semantic Versioning Specs, item 4:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

(http://semver.org/#spec-item-4)

Here goes the main question: why the project leads are so afraid to break backwards compatibility (taking into account we're at 0.x)? Sure, there are many mods based on "stable releases", but isn't it the time to move forward, especially at this development stage?

(And I'm sorry for another "holywar" thread.)

[red-001]

because we are only using semvar in theory.

[Fixer-007]

There will be 0.5 soon with some major changes.

[C1ffisme]

I actually agree. An outsider would look at this as an incomplete project, because we don't have a 1.0.0 and the README literally says "This game is not finished".

The problem is that on the inside, Minetest has both:

• None or very little agreed-upon sense of direction
• Years of nostalgia that people don't want to give up

So we get people saying that the game isn't complete, that it is, and that the game will never truly be complete all at the same time.

[rubenwardy]

We don't use semvar at all, it only looks like it.

What we're using is basically this:

0.major.minor

So we try to keep compatibility between minors updates to a major version (eg, 0.4.15 -> 0.4.16),
but we can break on major updates (0.4.16 -> 0.5.0)

I'd much prefer if we started using semvar, however

[bigfoot547]

Will the first thing stay 0 forever?

[nerzhul]

i also want to use semvar as 0.4.16-dev is for releasing 0.4.17 which is absolutely not logical

[paramat]

Concerning the 0. thing, i like it as it suggests humble 'incompletedness' and i dislike the idea of MT being considered 'complete', it's always better to feel like there is much to improve even if it is already very good.
There was a suggestion to jump straight to 5.0.0 to keep a number continuity from 0.4.z.

(Following MC dev it feels like the high point was before 1.0.0 and it has been downhill since then and since Notch left. To make it more mainstream and commercial 'The End' was unfortunately added just before 1.0.0, a final boss battle seems out of place in an open-ended voxel game.)

[Wuzzy2]

Minetest never used SemVer. Note that not every version with 3 numbers separated by periods is a SemVer. In most of the cases, this is just a coincidence. Only a very few software projects are actually using SemVer, and those which do so state this explicitly.

Also, this has been discussed before:
https://forum.minetest.net/viewtopic.php?f=3&t=10848&hilit=semver#p166143

I am in favor of MT adopting SemVer from 0.5.0 on. What I like about SemVer is that it makes breaking changes (from 1.0.0 on) very visible, so this is a good push to consider breaking compability to be of serious business.
SemVer will force developers to think before breaking compability, which is a good thing.

Concerning the 0. thing, i like it as it suggests humble 'incompletedness' and i dislike the idea of MT being considered 'complete'

1.0.0 usually signals “completion” in the sense of that it is reasonably polished, is fully playable (and enjoyable) and tested well. What it does NOT mean it is the final version ever. But this is just a convention. Also, there is no limit on updates after 1.0.0, which makes this “just” a milestone.
But well, I fully agree that Minetest can definitely not be considered to be of “1.0.0” quality right now. It's in alpha stage. There are simply way too many bugs and issues which need to be addressed: APIs are still unstable, incomplete and in flux, etc.
However, that doesn't mean there should never be a version 1.0.0; I hate the idea of “perpetual beta” or even “perpetual alpha”. This is just a very lame excuse to not fix bugs.

I think 1.0.0 could be considered a major milestone at which point the core APIs are complete, no longer in flux, core features are done, bugs are fixed and breaking backwards-compability (no matter if worlds or Lua code) is considerd to be very serious business. I think having such a milestone is critically important. Please remember that Minetest is an engine! If you are not even planning to eventually stabilize the APIs, it's not a good engine.

There was a suggestion to jump straight to 5.0.0 to keep a number continuity from 0.4.z.

This looks a bit like cheating to me as it elegantly hides the fact that Minetest is still in alpha stage. Any version larger than 0 is usually considered feature complete.

Following MC dev it feels like the high point was before 1.0.0

This is completely irrelevant to MT development.

[Wuzzy2]

You can easily read the SemVer rules on http://semver.org/, but here I write down some implications for Minetest if SemVer will be adopted:

• As long you are openly in alpha or beta stage (leading 0), you are free to break anything
• If future releases will be like past releaases (many features and bugfixes), it is almost certain that only the minor number will increase for many releases to come, so there will be 0.5.0, 0.6.0, 0.7.0, etc.
• The final number should only increase for pure bugfix releases, which is not how past releases worked. If future releases work like in the past, this number will almost never increase, unless you start to release hotfixes which really only contain bugfixes
• The current meaning of “-dev” versions has to go and must be completely rethought. As there are many conflicts with SemVer:
  • 0.4.16-dev currently means it is after 0.4.16, but in SemVer this would be a version before 0.4.16
  • Currently, 0.4.16-dev can refer to any version. This is not allowed in SemVer, in which all versions must refer to a single state of development (i.e. commit).
  • No matter how you want to change this, I think you should something else than “-dev”, to avoid confusion
  • It needs to be clarified how an arbitrary in-development version (commit) should be displayed in-game. At least the commit ID should be visible
• There must never be a version number which can refer to 2 or more states of development/commits
• As soon you hit 1.0.0, you are entering “serious business” terrain, but it is also an important stability promise to the modding community
• 1.0.0 should be considered a major milestone; it should be planned to reach it. If you stay forever in 0.x.y, SemVer is pretty much pointless
• The fact that SemVer is used should be written down somewhere, so that it does not get overlooked

[nerzhul]

a program is never complete. World of warcraft is currently in 7.2.0 version, each major version is complete version with many features and has breakages. If minetest cannot be finished zero has no sense in our version scheme except symbolic. For the semver we must use it yes.

[nerzhul]

a program is never complete. World of warcraft is currently in 7.2.0 version, each major version is complete version with many features and has breakages. If minetest cannot be finished zero has no sense in our version scheme except symbolic. For the semver we must use it yes.

[C1ffisme]

Following MC dev it feels like the high point was before 1.0.0 and it has been downhill since then and since Notch left. To make it more mainstream and commercial 'The End' was unfortunately added just before 1.0.0, a final boss battle seems out of place in an open-ended voxel game.

What you have heard is the message from nostalgia freaks. With every Minecraft version, there are complaints, just saying that Minecraft 1.0.0 was complained about is taking it out of context.

And besides that, take my personal experience: I started playing Minecraft when 1.4.5 was out, and I still play it to this very day.

</offtopic>

[ghost]

Following MC dev it feels like the high point was before 1.0.0 and it has been downhill since then and since Notch left. To make it more mainstream and commercial 'The End' was unfortunately added just before 1.0.0, a final boss battle seems out of place in an open-ended voxel game.

But I must admit that Mojangs relöease and development philosophy was awesome! They did not use SemVer but they released bugfix versions figuratively (and sometimes literally) every other day. They were super open about the project's status, they listened to the players, they implemented suggestions by players on Twitter, they had a regular release cycle for weekly builds, etc. (I wish MT devs would be at least half as open and communicative as the Mojang team was before the MICROS~1 disaster.)

Unfortunately Microsoft stepped in and ruined it completely.

To SemVer: Use it or not. But stick to it. Using arbitrary strings as versions is fine, too. But make it at least somewhat consistent and use tags for the versions in the Git repository!

[NathanSalapat]

@dsohler please keep in mind that Minecraft had paid employees and lots of them, whereas we have volunteers, and only a handful of them. There is only so much that can be accomplished with a small volunteer team.

[ghost]

@NathanSalapat yes, that is correct. I just like to remember the glorious times of Minecraft 😄

[realvictorprm]

Take your time with the next version, pretty nice stuff here!

[Wuzzy2]

Hmm, this issue is now open for quite some time, but no decision on the actual question whether to switch to SemVer has been made.

If you are not willing to change the versioning scheme, please just say so and close this issue.
Or make a statement if you are actually for switching to SemVer.

I don't think it makes sense to keep this issue open forever. I would of course welcome a switch to SemVer (if done seriously), but it is not terribly important and not the end of the world if the current versioning just stays like it is now.

[C1ffisme]

@Wuzzy2 Honestly, I don't consider this game complete at all. Sure, the engine is pretty good right now, but there are things I find could be more graphically pleasing or some things that the engine still doesn't do well yet, such as client-side sound. As for MTG, that's definitely nowhere near being a creative sandbox or an enjoyable game.

For now, I actually think the Versioning is fine, it's more the slow development pace that I can't stand. (Which isn't really a problem that can be solved without more people collaborating.)

[SmallJoker]

The in-development version issue, going from 0.4.16-dev to 0.4.17, is changed now to the correct 0.4.17-dev.
We decided to continue with 0.5.0 as the next release. Jumping to 1.0.0 with even more breaking changes will again cause problems when players would like to play on a server. Servers aren't going to update quickly, so having a mess of up to three Minetest versions to play everywhere is quite user unfriendly.
For now, I don't see a point in changing the scheme - after a few 0.5.x releases this might get to a discussion again.

[paramat]

I think right now is an excellent time to drop the leading '0.' and move to major-minor-patch.

• We are now preparing for the release of 0.5.0, being a 'major' change this is obviously the right time for such a change, so that it is called 5.0.0 and the added branch is called 'stable-5'.
• This will stop the annoying comments about 'MT being in beta' and 'what needs to be done to "complete" MT for 1.0.0 release' etc. :) Semver 1.0.0 was actually many years ago and moving to 5.0.0 gives a nice sense of 1.0.0 being distant history so that we are not bothered by the associations and expectations created by it.

Any support?

[nerzhul]

i prefer the 5.0.0 as it's the 5th major MT release. A software is never complete. Look at grep, ls and other tools, they seems complete but they are patched like any other software.
For the -dev, yeah we changed this in 0.4.17 because you prefix the current future version, (0.4.17-dev is to release 0.4.17, you have same thing on Java with 1.0.0-SNAPSHOT releasing 1.0.0)

[rubenwardy]

I agree. Shall we vote on it? I suggest doing alternative vote on options: 5.0.0, 2.0.0, 1.0.0, 0.5.0.

• 5.0.0 - just drop 0.
• 2.0.0 - 0.4.1 would be 1.0.0, so this would be 2.0.0 if we followed semvar
• 1.0.0 - has bad connotations imo, this isn't a finished release as such
• 0.5.0 - boring

This is coincidentally in order of my preferences

[Iniquitatis]

@paramat I think it will be a better option than "0.x.y". But there's still several issues with this decision, for example we still don't have any mobs, nor the UI is finished by any means. I feel that there still will be many people who is opposed to this versioning scheme switch.
Still, +1 on this decision.

@rubenwardy Hmm... Actually, I'll go with the first option. "1.0.0" is something, what will lead people to think that this version is a feature-complete release. "2.0.0" makes almost no sense. So, my vote goes for "5.0.0".

[nerzhul]

@Iniquitatis read my comment. World of Warcraft 1.0.0 has no PvP but it have in 1.4.
I really think a C++ mob engine (or at least LuaEntitySAO with very high level AI implementation).
We cannot release a perfect 5.0.0, but at least we have 5.1 to add more features, and 6.0 for future C++17 breakage in 5 years :D and 5.0.1 to add critical bugfixes

[Ezhh]

I think MTG not having mobs shouldn't have anything to do with such a decision. MTG is just one game, even if it happens to be the only current official one (Content DB is going to give other games more visibility now anyway). The engine certainly can support mobs either way, and shouldn't have to base decisions about versioning on the state of a single game that uses it.

I'd prefer to drop the zero and see 5.0.0.

[Iniquitatis]

@nerzhul Community reaction is something that should be considered. "1.0.0", I think, will lead to more questions and negativity than "5.0.0". Though, I might be wrong.

(And I don't think that PvP is mandatory to MMORPG genre. :P)

[rubenwardy]

Yeah, releasing > 0. just means we have interversion support (which we aim for anyway)

[paramat]

for example we still don't have any mobs, nor the UI is finished by any means.

Yes mobs are a game thing, the engine supports mobs :) The UI has technically been finished and functional since MT 0.3, just not very pretty and formspecs are not good to work with.

I don't think the community will mind much at all, most know MTE has been post semver 1.0.0 since MT 0.3. If they don't they need to learn that :) The perception that MT is 'beta' and incomplete/not fully functional is annoying and is best corrected.

5.0.0 creates a logical and undramatic continuity from 0.4. Anything else (like 2.0.0) is too dramatic a versioning change and creates expectations of 'completemess' (or even 'completeness').

[paramat]

the README literally says "This game is not finished".

Good point, this should be removed.

Honestly, I don't consider this game complete at all. Sure, the engine is pretty good right now, but there are things I find could be more graphically pleasing or some things that the engine still doesn't do well yet, such as client-side sound.

This is the mistake of interpreting personal disatisfaction with some aspects as meaning MTE is 'in beta' and 'pre-release'. It has been fully functional since MT 0.3 ("the engine is pretty good right now"). It will never be 'finished' or 'complete' as there will always be more to do, and will always be lacking in the opinions of some people.
This is an example of what i mean by 'the annoying comments' :)

[paramat]

PR #7440

[Iniquitatis]

@paramat Sorry, I might be wrong, but I still don't see an API for mobs anywhere (in the wiki, codebase, etc.), which means that potential (sub)game developers cannot fully rely on this part of the core engine.
As for formspecs, there was many discussions about modifying/replacing/scrapping it, and there are still no decision on this topic.
(Hasn't been there for about a year, though. Is this formspec situation changed?)

[nerzhul]

entities are not mobs. We need really a mob API. I think it's a good candidate for a 5.1.0 version, 5.0.0 has sufficient features, now we need to polish remaining points

[paramat]

Yes we don't have a specificly designed mob API :) But various general APIs exist to make mobs completely possible so i consider mobs well supported by MTE.

[paramat]

Support stated for '5.0.0': paramat, rubenwardy, Ezhh, nerzhul
Neutral: SmallJoker, sfan5, sofar, nore:
http://irc.minetest.net/minetest-dev/2018-06-12#i_5330497
http://irc.minetest.net/minetest-dev/2018-06-12#i_5330899
http://irc.minetest.net/minetest-dev/2018-06-12#i_5331091
http://irc.minetest.net/minetest-dev/2018-06-13#i_5331937

@lhofhansl @ShadowNinja @celeron55 ?
EDIT: Updated with nore's opinion.

[ClobberXD]

5.0.0 sounds good to me, taking into consideration this comment by paramat.

The first digit doesn't seem to be changing anytime soon. If it's going to stay '0' all the time, it might as well be dropped. :)

[VanessaE]

I'm no core dev, but I say just go for it. 5.0.0.

[nerzhul]

@paramat yes we have good mods, which are a good basic for a powerful core engine API :)

[paramat]

Looking at updated #6073 (comment) i suggest this is officially decided as semver 5.0.0.
The section at the end of README.md will need editing.
EDIT: This is not a decision for semver or strict semver, but for major.minor.patch.

[Wuzzy2]

You still have failed to specify what to do with -dev. :-(

Note that a version of form X.Y.Z-somewords in SemVer refers to a single, released, specific version, not a range of versions.
So using 10.0.0-dev to refer to any commit before 10.0.0 is illegal under SemVer.

However, SemVer has an alternative to -dev, which is builld metadata (rule 10):

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

[paramat]

See https://semver.org/ for the spec.
I was under the impression it did not have to be followed strictly, if it does we can't use semver because:
"Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated."
This would increment minor every 4 commits or so. We will be incrementing minor per release as currently.
EDIT: Misunderstood.
There may be other rules that would be silly and unnecessary strictly follow.

So i oppose strict semver. If semver has to be strict then i think we should just use our own major.minor.patch scheme "that is similar in some ways to semver".

I'm not sure what the thread author means by using semver, strict or not?

[paramat]

The core devs are expressing their support for '5.0.0' not strict semver. My comment above #6073 (comment) asking for opinions is about dropping the leading 0, not about semver.
Using semver (strict or not) is independent of this decision.

[rubenwardy]

Actually, it is support for semver too however it doesn't need to be as strict as wuzzy says. As long as major, minor, and patch are used correctly the interversion code doesn't really matter too much. We already have a commit hash in the version name given in-game anyway, which is the same. M.M.P-dev is just a convenient way of referring to the development branch.

[paramat]

Edited my comment above as i misunderstood minor incrementing.

[Wuzzy2]

You are always free to “steal” certain aspects of SemVer without following it religiously. But then just don't claim you are following SemVer unless you really commit to it.

[nerzhul]

See #7449

[nerzhul]

I added the version bump PR, the strictness of the version management doesn't depend on this version specifically but for patch releases & minor non breaking releases