questions about 1.0.0 (not 0.10.0)

[jjmafiae]

this is not about the next version of Löve (0.10.0) but 1.0.0.

Okay so what would be required for Löve to be considered 1.0.0 ? (is there a roadmap ?)

[Jeeper]

I remember reading something about "total world domination".

[Inny]

If the Love guys are using Semantic Versioning, or something like it, then the leftmost number is how many times they've rewritten or massively refactored the code (or significantly broken any source compatibility if being used as a library). So, ideally they wouldn't ever reach 1.0.0, if that were the case.

[Evine]

If the Love guys are using Semantic Versioning, or something like it, then the leftmost number is how many times they've rewritten or massively refactored the code (or significantly broken any source compatibility if being used as a library). So, ideally they wouldn't ever reach 1.0.0, if that were the case.

Since that will never happen the next version should be called Löve 10.0

Didn't Rude know that lua had 1 based indexing??? Maybe Löve 1.10.0 is better.

[I~=Spam]

If the Love guys are using Semantic Versioning, or something like it, then the leftmost number is how many times they've rewritten or massively refactored the code (or significantly broken any source compatibility if being used as a library). So, ideally they wouldn't ever reach 1.0.0, if that were the case.

Since that will never happen the next version should be called Löve 10.0

Didn't Rude know that lua had 1 based indexing??? Maybe Löve 1.10.0 is better.

Ummm I am not entirely sure if you being serious here... The two are very different. Lua has tables start from 1. This doesn't mean that the standard is to start program version numbers from 1. In fact just the opposite is true. version 0.x usually either represents some sort of beta or an official release. On the other hand, 1.x usually represents an official release.

There isn't any reason to start the version numbers from zero (in fact there is only reason to do just that because it would be confusing otherwise).

Lua chooses to start indexing from 1 (in tables; not version numbers) for a variety of reasons. If I understand correctly there are two main reasons.

1. At first there was no standard. Those who wrote programs in lua simply just used indexing that started from 1 not zero. So the authors made it official. (I might be wrong about this one... but I am pretty sure I remember right.)
2. There is no penalty in wasted space like there would be in an array in c/c++ so why not?

EDIT:

If the Love guys are using Semantic Versioning, or something like it, then the leftmost number is how many times they've rewritten or massively refactored the code (or significantly broken any source compatibility if being used as a library). So, ideally they wouldn't ever reach 1.0.0, if that were the case.

I like this versioning style. There are a few issues with it though. (Mainly it is harder to differentiate between bigger releases.)

[Robin]

That's not how semver works.

1. The major version (the x in x.y.z) is increased for every version that is backwards incompatible with the previous version. Rewrites have nothing to do with it: going from 1.2.4 to 2.0.0 could be a trivial change in the code base (as long as the API changes), and going from 1.2.3 to 1.2.4 could be a complete rewrite (as long as the API stays the same)
2. For versions where the major version is 0, like LÖVE is on now, the above doesn't hold, and 0.2.0 could break the API from 0.1.0, or it could not.

[source]

I don't know whether the devs will use semver once 1.0.0 is released, though.

[Nixola]

It looks to me like they're using x.y.z where x is 0, y is semver's x and z is semver's y. Then semver's z should be reserved for LÖVE bugfixes, I think, but those don't get a release (like the infamous "print space on ATI" 0.8.0 bug).

[slime]

It looks to me like they're using x.y.z where x is 0, y is semver's x and z is semver's y. Then semver's z should be reserved for LÖVE bugfixes, I think, but those don't get a release (like the infamous "print space on ATI" 0.8.0 bug).

There was going to be a LÖVE 0.8.1, but it got rolled into 0.9.0 instead.

[Inny]

That's not how semver works.

1. The major version (the x in x.y.z) is increased for every version that is backwards incompatible with the previous version. Rewrites have nothing to do with it: going from 1.2.4 to 2.0.0 could be a trivial change in the code base (as long as the API changes), and going from 1.2.3 to 1.2.4 could be a complete rewrite (as long as the API stays the same)
2. For versions where the major version is 0, like LÖVE is on now, the above doesn't hold, and 0.2.0 could break the API from 0.1.0, or it could not.

[source]

I don't know whether the devs will use semver once 1.0.0 is released, though.

I'd always interpreted it as

1. Patch Version: Safe to replace binary, ABI is stable.
2. Minor Version: Not safe for binary replace, recompilation necessary, but API is stable.
3. Major Version: Not safe for recompilation, API changed, developers need to fix code.

So that automatic build systems for linux distros could safely apply security changes without rebuilding, or could identify that just rebuilding wasn't enough and that upstream developers needed to get involved.

[T-Bone]

I think it makes sense to call it 1.0.0 when the API is more or less frozen. And I think that should happen pretty soon, because Löve already has by far the best API among game frameworks.