let me give a useless dev answer with too many words
You are describing the SemVer.org system (aurthored by the co founder of GitHub, the main code sharing platform of the internet) If you read their guide, the numbers you see above may actually be valid, but I think the publishers did not format them correctly, or you may not be as familiar with the SemVer system as developers may be (the SemVer is for devs, not for end-users, as it is mostly used to describe changes in code, not in games). What may be happening is that each game uses a different game engine, with a preset up SemVer config, but each one is a bit different and the export gets a different version number configuration, and the dev's may not know the proper versioning format to be able to correct it, and just accepts what the compiler spits out.
The examples you gave may be valid version numbers because the numbers are pre-release version numbers, and pre-release versions have lower precedence (SemVer Rules # 9 and 11), so they actually work backward.
Here is a valid order of release version,
"Title" 0.0.0 #First starting a project
< "Title" 0.5.1 #Fith prototype public build, with a small fix
< "Title" 1.0.0-x.7.z.92 #This is not the released version 1, This is a pre-release version, getting ready to be version 1, trying to get the last of the bugs fixed before actually releasing. I have no idea what x.7.z.92 means, it was just the example on their site. For projects, I would actually use -alpha.minor.patch and -beta.minor.patch, and patches would be letters, not numbers. Technically the two previous examples are pre-releases, without 1.0.0 in front of them, or 0.0.0 because you are just experimenting and not trying to reach a goal, where Major numbers imply a goal.
< "Title" 1.0.0 #The actual release of the product
< "Title" 1.0.1 #Added a fix or two
< "Title" 1.1.0 #Added a bit of content
< "Title" 2.0.0 #Added major content, area, system etc
< "Title" 2.0.1-alpha.0 # "alpha.0" is a test for patch 1 of released version 2.0
< "Title" 2.0.1 # the patch has been released and implemented
< "Title" 2.1.0-alpha.0 # a test of a new minor update
< "Title" 2.1.0-alpha.0.a # the same test, but with a patch
< "Title" 2.1.0-alpha.1 # Trying to add the same new content, but the test is different a bit (like a minor version)
< "Title" 2.1.0-beta.0 # The minor update is almost ready, just some polish is needed.
< "Title" 2.1.0 # the minor update has been released!
= "Title" 2.1.0-1.0.0 # This is the same thing as the previous line. the alpha and beta are now 1, just like when first making a game. If you wanted to make fix version 2, you would just make 2.2.0, and start at -alpha.0 again.
= "Title" 2.1.0-1.0.0+334.3-0.0 #This is the same thing, but there is the build metadata as well for the programmers. build Metadata is ignored when determining version precedence. Different people may use different build metadata depending on their techniques or tools
I personally prefer
"Title" major#.minor#.patch#-versionTag.versionTest#.attempt@+merge#.attempt#-branch#.(Branch# for sub branches).0
First part is Public versioning, meant to be user-readable. It is meant to indicate to humans that it is a usable file.
The second part after the - is still a user-readable version number, but also meant for the active devs and team, and meant only as pre realesed file, not really for users, but maybe for playtesters. It is meant to indicate a testable file to humans.
The third part is the build metadata, meant only for the programmer, so that they can load up that exact version to start making changes. Not every build works or is ready, use the other previous version types to figure out what a build is supposed to be, and any random build number, could be non-operational, any branch not ending in zero (using my system) is still being edited (open on a computer) and is only acceable to the programer until they save their changes.
Where # indicates a number, @ indicates a letter
Version tags can be alpha = first implementation, and beta = refining to finish. with 1.0.0 = complete
The Build metadata can be whatever, but I use my own metadata type as it allows for infinitely multiple, unbounded dimensions to describe exactly what version of code I am at, as it does not require branch merge order constrictions like with github and other tools, and it is easier to track by hand than a hashed code.
if you are interested in my metadata, it equals the id of a specific build. it is broken into two parts mergedata-branchdata. mergedata = merge#.attempt# where merge# is an arbitrary number, however, by selecting it and looking it up (such as clicking on it if I ever make an interactable software for it) you can see the two builds that were combined to make this merge#. This allows for multidimensional merging, that is not dependant on master branches or merging upwards only. attempt# is my own feature, to allow new merge definitions to allow the computer to automate fixing game-breaking issues that got buried deep into the code after many builds, I don't think this is unique to my system. branchdata = a list of branch #'s all separated by '.' with each new . indicating another branch built off of another (it is like testing an idea, and then building on top of that idea, before releasing the idea to the public, like minor versions, of unlimited dimensions before the major release, but you can still go back and forth in time). the branchdata must end in .0 to specifically state that we have reach the end, we want to look at the branch listed, and not get confused with the sub branches .1 or .x.y.z. and that at this point the branch may no longer be modified. to add to the branch or make changes, make a new branch (a new build).
Edit: also, staring a version number with v is incorrect formatting, you can write it and say it, but it should never show up in code. Second to the last FAQ
