We've barely moved more than 0.2 forward in 6 years.

I suggest we move to something like the Wordpress versioning system, where we increment by 0.1 everytime we release, and only use 0.0.1 additions for security and hotfixes. Any release that has a new feature should be a 0.1 addition.

So the next version wouldn't be 0.83 it would be 0.9, then 1.0 then 1.1, and any fixes or quick bug releases to the next major version would be 0.9.1 etc Numbers such as 1.0 and 2.0 would have no more weight than 0.9 or 1.1

It's embarrassing having a 0. at the beginning of every version number, and a proliferation of decimal points. Numbers such as 0.82.1 or 0.82.3.1 sound silly and arbitrary. The last thing we need to have is a 0.99.9.12 in 15 years time, and if we were looking to have the engine introduce some completeness then we should have moved to 1.0 when we added lua gadgets.


We're at 10 months since the last bugfix release, at this rate we'll reach v1.0 in 15 years.

read http://springrts.com/phpbb/viewtopic.php?p=501948#p501948

When I read that I took it to mean the next release will be v0.83 publicly and v11.2 internally in git.

Further testing threads made since have reinforced this notion by using 0.83RC as the version number.

I sincerely hate the 0.versioning scheme. It's needless wank and is absolutely meaningless.

Signs indicate we're on the verge of incrementing by 11.18 rather than 0.01 on the next release! Queue the "Where's v9 and v10?" MTR

it should be clear from the following sources:
the last testing release
the last (released) meeting minutes
the branching and versioning RCs (specifically RC 13)
... that the next release will be:
83.0

if you want to know details, read any of the above, which are interlinked.

All releases will have one dot, not more not less. the second number is unsynced-patch-set.

Yikes, if someone does a count of all the releases and figures out the actual number assuming that the first release by the SYs was 1.0 will you adjust accordingly so we can use this scheme without silly high numbers?

real the meeting minutes.

I did, and saw no justification for starting from 83 other than the next version would have been called 0.83, which was assumed and not stated.

I don't understand the need for any change

well.. read again AF.

if you don't understand why we change even after reading all the info, i guess i can't help.

Perhaps what I should say is - I don't see what advantages the removal of the initial "0." brings

2 less characters?

I understand why you changed to the new versioning scheme. But as I see it, under the new versioning scheme, someone asked what we should use for the next version, values such as 10 11 and 83 were passed around, and everyone kind of agreed on 83.

Since I wasn't present on the meetings, and since it would take me hours to read again, and since I've quite clearly missed what your referring to in my first run through of the text, perhaps you can save yourself time by typing the reason out instead of wasting your time by repeatedly typing out rtfm in uber verbose ways that take more time to type than simply answering the question.

And if you cant answer the question in less than 30 characters then perhaps the wrong decision (or none) was made, and you should think of an answer because lots of people will be wondering why we've just jumped 83 versions ahead, or why we didn't just start from v1

Edit: For some reason I repeated myself needlessly.

Nah, when used right version numbers give a rough idea what you get. Is it only bugfixes, some new features or an entire rework?

read the minutes ...

@vbs, quite true, but on the same grounds, I would argue that spring has never used them "properly".

Why not just start from 1.0 if the version is to be changed anyway? Jumping to 83 sounds insane, especially since we havent had that many versions. (You who want to hive the version up to 83 should start working for the Italian government.)

Why have a version number that doesn't mean anything?

if it works for the devs, what does it matter?