I usually name everything as 1.0 etc. So I’d have Pre-Alpha 1.0 and Beta 9.0 and stuff but i know that isnt correct. So how does Minecraft and all the other companies name their builds and stuff?
Either I go with major.minor.patch, e.g. 1.83.2 or just count releases, e.g. r105 or v46
Lately I just count, because none of my projects are sophisticated enough to need a complex versioning scheme.
Thanx Varkas, +1
What I do is count each major release and add a decimal each minor release. So a main release could be 2 but the next realese could be 2.1 because I just fixed some minor bugs or something.
Thats currently what im doing now. I guess my method isnt that wrong after all!
For me, I break the mold and do it all by build date. Whatever the date is when I compile it for release is the “version number”. If I release 2 copies in the same day, the second becomes a B copy (IE: InDev-2-27-2014b)
Assuming we use today’s date…
While the game is in pre-alpha, and really not a playable game yet:
InDev-2-27-2014
Once in Alpha (Meaning there are some functional, actual game play elements at this point and the game is starting to actually become a “game”)
Alpha-2-27-2014
Beta (majority of the core mechanics are completed, just lacking content):
Beta-2-27-2014
…and Release, I just call them “Builds”.
Build-2-27-2014
I like the way that looks… Maybe i just have a number fetish idk, but i think i might use your way of doing things it looks nice!
I personally find that very ugly to look at. Sure, its a decent way to label your builds, but it’s A2.1 or B0.1 or something much simpler to read? A - Alpha, number for the version.
I agree, it can look messy sometimes. But it’s a much better option than having something like V3.352.22b2 eventually. Of course, on smaller scales that will never happen really. But I’ve seem some wild patch numbers in some of the bigger budget titles out there 
There’s a few benefits to my system, but yeah, it can cause a bit of a mess to look at. I just like being able to quickly load up “Build 7-21-2013” (for example) and see where I was 6 or 7 months ago. I don’t have to do any real extra work to figure out what version I was on 6 months ago. I just load up the build from that date and go. 
A, B for development state and then major.minor.build
yeah, Major.Minor.Patch is a very common method. Although I’d argue Mojang doesn’t do it right. For example, they have “beta 1.7” and “release 1.7”. Sort of confusing.
What they really should have done is 0.x.x for beta and then 1.x.x for release.
Now they have an odd problem with beta and retail patches overlapping, makes it really confusing when you read posts about “1.7” and unless you check the date, you might end up getting info on 1.7 beta from 3 years ago instead. 
I use 0.0.0-1.0.0 for alpha/beta. For patching I’ve just went with something like 0.4.5.1 (extra decimal for patch) then usually if needed, a letter if different patches for different is/hardware etc
At the moment I usually do it like this:
@version Major.Minor[.Build] (Day.Month.Year)
So I have the version and the build time. 
You could also get more information about Versioning here. Interesting to read
By the way in Visual Studio Versioning is like this:
Major.Minor.Build.Revision
I love using the dates for versioning in my personal projects. But for big projects, (major)(minor)(patch) is the easiest for users to understand and causes less confusion for the team when we talk about it
I always call my development builds ‘DevMo’ builds, ‘DevMo’ being short for ‘Developer Demo’. Never saw the point in naming builds ‘Pre-Alpha’, ‘Alpha’, ‘Beta’, and so on.
As for numerical versioning, I always use this: [icode][Month] Major.Miner.Patch[.Fix][/icode].
- Jev
I like the major, minor, patch system, but not the format. X.X.X is a bit weird and implies there should be a few versions between x.(n).0 and x.(n+1).0, when really those are just for hotfixes.
So I use a letter for the patch instead, and patch 0 has no letter.
Eg: 1.1 is second minor version after 1.0 and 1.1c would be the third patch for that version (If that many bugs manage to slip through)
When I’m just hacking away at something with not much in mind I call it version X.X-Dev. Where X.X is the next proper version.
For alphas/betas, I use X.X-Beta and X.X-Alpha respectively.
It means version numbers can be kept separate from build types and both easily identified.
1.0 or 1.1 works pretty good
If you simply count, it’s really easy to auto-update the version number from inside your build-script. 
Take a look at semantic versioning
http://semver.org/ describes it in details and explains why it matters.
It might be overkill for a game project which is never linked to by other binaries but it does not hurt to use standard that is widely accepted and uderstood. (Semantic versioning is suggested versioning by github)