Closed Dunbaratu closed 11 years ago
There might be a problem, after 0.9, because usually viewed from the standpoint of version numbers 0.10 > 0.9 although mathematically it is 0.1(0) < 0.9. Maybe instead a revision which increases by one each version.
Fabian
Then two different numbers. versionMajor and versionMinor.
Actually three numbers ;) one for 0
, one for 9
and one for 3
(if 0.93 means 0.9.3).
Fabian
Make up your mind. In order for 0.10 to be higher than 0.9 you must specifically NOT be treating the three digits of 0.10 as separate parts, but be treating the 10 as one part. If you're claiming 0.10 is higher than 0.9, then you are claiming the three digits aren't 3 different parts. If they were 3 parts then 0.10 would be 0.1.0 and your original complaint would be moot because 0.1.0 would not be higher than 0.9.
If each digit is a separate sorting criterion then it works just like normal numbers do.
0.10.0 it is. There was a version 0.6 an then 0.65 was released which is actually 0.6.5 so after 0.9.x you have 0.10.0.
Of course the current version could be treated as 0.84 so the next one would be 0.85 and so on.
I think that makes the most sense.
So we'll basically have a major, minor, and revision. And if we're not ready for a 1.0, we'll go to 0.10.0.
It would be nice to be able to have a thing like this:
or, similarly, to change behavior depending on known issues in certain versions.
In trying to make examples for people to follow on the community wiki I'm running into the problem that the script needs to behave differently depending on the KOS version number.
Obviously this wouldn't let you query version numbers lower than the version in which it is first introduced, but it would be a nice for the future after that. (Thus why I used version 0.93, which doesn't currently exist, in my example. It's an example of the sort of code someone could write in the future after this feature was around for several versions.)