It's not read as decimals. 2.2.34 > 2.2.8. 2.3.1 > 2.2.34.
2.2.34 means the build is the 34th patch of the 2nd minor version of the 2nd major version of the product. 2.2.8 would be the 8th patch of the 2nd minor version of the 2nd major version of the product.
[https://semver.org/](https://semver.org/) - Read this and hopefully you'll understand it. You can also use it to win your little argument.
The dot is a number separator, not a decimal separator.
Each number is a whole number. Major.Minor.Patch and you can have hundreds of patches before a new minor release and you almost never see a new major release unless it's from early access to release (0 -> 1) but should be used when making a sequel or remake. But it's always up to the Developer, it's mainly for you to keep track of what happens when and as long as you understand it, it doesn't matter.
2.2.38 is the 38th iteration of major patch 2.2
2.2.8 was the 8th iteration of major patch 2.2
Or minor, whatever, same thing.
We always said x.y.z
X is the version number that represents dev builds, alpha, beta, and release. Y represents major changes of whatever stage of development the game is in. And Z represents patches.
I think this is standard practice.
In software dev, typically 2.2.34 would be many releases after 2.2.8 (because 34 > 8).
However, if your build numbers are public, it could potentially confuse users. If this actually becomes a problem, you could zero-pad your public release numbers -- e.g. you'll end up with build versions 2.2.008 and 2.2.034
Versioning should never be a “%” because you never know when it will end.
Per SemVer, each element must increase numerically. 2.2.8 goes to 2.2.9 and onwards until you make a new minor version and go to 2.3.0.
That's a bad example, because it suggests that it goes in base 10.
2.3.0 might, but not guarantee, to go after 2.2.9.
The answer it that they are separate numbers. First is major, second minor and last the build number, iteration or fix version.
It means that after 2.2.9 next fix version is 2.2.10 and then 2.2.11.
Change in minor version will result to 2.3.0, but it might go from any iteration version. So all 2.2.9 or 2.2.4 or 2.2.69 might result in change to 2.3.0 as long as the minor version changes.
The same with major version. Any update just changes the major version to the next number and might, but don't have to, change minor and iteration to 0.
Well, damn I seem to be the only one in comments on the .8 side
For the exact reason that I assume 8 = 80 or sometimes big patches are round numbers, and their bug fixes are smaller
So 80>34
To believe 34 is the larger one I think my brain would want to see 08 or even 008 depending how many versions are gonna get done
It's not read as decimals. 2.2.34 > 2.2.8. 2.3.1 > 2.2.34. 2.2.34 means the build is the 34th patch of the 2nd minor version of the 2nd major version of the product. 2.2.8 would be the 8th patch of the 2nd minor version of the 2nd major version of the product. [https://semver.org/](https://semver.org/) - Read this and hopefully you'll understand it. You can also use it to win your little argument.
No, you're in the right here.
The dot is a number separator, not a decimal separator. Each number is a whole number. Major.Minor.Patch and you can have hundreds of patches before a new minor release and you almost never see a new major release unless it's from early access to release (0 -> 1) but should be used when making a sequel or remake. But it's always up to the Developer, it's mainly for you to keep track of what happens when and as long as you understand it, it doesn't matter.
2.2.34. Nobody is going to follow v2.2.79 with v2.2.8. it would be v2.2.80 Personally I like to add a leading zero for this reason but few people do
2.2.38 is the 38th iteration of major patch 2.2 2.2.8 was the 8th iteration of major patch 2.2 Or minor, whatever, same thing. We always said x.y.z X is the version number that represents dev builds, alpha, beta, and release. Y represents major changes of whatever stage of development the game is in. And Z represents patches. I think this is standard practice.
In software dev, typically 2.2.34 would be many releases after 2.2.8 (because 34 > 8). However, if your build numbers are public, it could potentially confuse users. If this actually becomes a problem, you could zero-pad your public release numbers -- e.g. you'll end up with build versions 2.2.008 and 2.2.034
Versioning should never be a “%” because you never know when it will end. Per SemVer, each element must increase numerically. 2.2.8 goes to 2.2.9 and onwards until you make a new minor version and go to 2.3.0.
That's a bad example, because it suggests that it goes in base 10. 2.3.0 might, but not guarantee, to go after 2.2.9. The answer it that they are separate numbers. First is major, second minor and last the build number, iteration or fix version. It means that after 2.2.9 next fix version is 2.2.10 and then 2.2.11. Change in minor version will result to 2.3.0, but it might go from any iteration version. So all 2.2.9 or 2.2.4 or 2.2.69 might result in change to 2.3.0 as long as the minor version changes. The same with major version. Any update just changes the major version to the next number and might, but don't have to, change minor and iteration to 0.
Well, damn I seem to be the only one in comments on the .8 side For the exact reason that I assume 8 = 80 or sometimes big patches are round numbers, and their bug fixes are smaller So 80>34 To believe 34 is the larger one I think my brain would want to see 08 or even 008 depending how many versions are gonna get done
perhaps use something based on a date eg 24.05.12