Versioning your Game

Hi all,

ok, I am currently working on my own minigame for mobile devices, showcase follows to a later point.

My question is, what are good practices to version your games in the process?

I googled that subject and found one good example on (link to question).
Ok, that sounds good. Nevertheless I would like to hear some of your best practices that makes the versioning a bit easier for all of us :slight_smile:

I am still having the problem to decide how to increment the version number or by what amount etc.

Do you have any thoughts on this?


1 Like

The link you posted has a pretty good description of it.
There is no official standard on it, but most people stick to the same format. ..

1.2.3 or sometimes

The first digit is your major version. You only change this number during significant code changes, where you’ve rewritten a majority of the code, or added so much to the last version that it is a huge milestone in your app/game development.

The second digit is for moderate revisions. You’ve added new functionality that has a big impact on the game, but its still the same game. You would change this one a lot more frequently than the first digit. It could be a UI overhaul, or adding networking, or character customization, new levels (where levels are a big thing, not like in things like block breaker), etc.

The third ( and fourth if used) digits are for minor revisions. Bug fixes, tweaks, adding small things (items, weapons) that dont have a huge impact on the game. Or in games where levels are not a moderate improvement, like block breaker.

Now, some people append the letter a or b, or alpha or beta releases 2.5.3b, or 3.1.0a, to let people know that these aren’t finalized releases, and may be (will be in the case of alpha) buggy. These are not versions you would submit to the app store, these are to send (or post on your website with a big warning of its not-finished-ness) to your testers.

I have seen some ridiculous version numbering, strings of numbers and letters that look like a CD key.

Keep it simple.


Thank you, your reply helps me a lot! Will keep your words in mind.

Using Visual Studio you are present with four levels, Major, Minor, Build and Revision. In the workplace for applications instead of games we only really ever used the first three, and the Build number was automated via Visual Studio, so you may get something like 1.2.1543 - it was most likely only of any real use to us when we were check what was on the server against what we have in source control/our pcs.

From a games perspective, I think seeing much more than 2 levels is a bit pointless from a users perspective. e.g;

Version 1.0 - ok, yep, get that, the first version…
Version 1.1 - w00p - a new version and it didn’t cost me anything, I feel fab
Version 2.0 - wowsers in my trousers would you look at all the new stuff in this major release!

Of course, if you are releasing very frequently, this may not work, as the version number can start to look a bit daft…

Version 1.96 - oh joy, they have change the text colour back to yellow from white, great…

Version 22.1 - really, you are on the 22nd major release of this application, really?!!?

I think it can lose it’s usefulness quite easily if you are not careful with your planning and releases.

Windows 3.1, 95, 97, ME, XP, Vista, 7, 8, 10 - waah?!


True, didnt see it from users point of view.
I guess I will release under 1.0 and if I update then I will increment the second digit like you showed 1.1, 1.5 etc.
Everything else is ireelevant in my case then ^^ and does not give the user any useful information.

Still good to know the different kinds of versioning.

Thanks guys!


You could always use the third level for an urgent bug fix release I guess… So, ordinarily, 1.1., 1.2 but then if there is something that is a real problem, 1.1.1?

As a user I like to see what’s changed, so having a nice change log that makes sense to me as a user I think can be handy. If you are telling me there is a new version great, but what do I get? I’ve seen games which always just push out the same comment Bug fixes and optimisations, well, yes, maybe that has been true, but really, everytime? That just feels lazy. Equally, there’s no point telling me about stuff that is a bit irrelevant. I bought an early access game on Steam called Stranded Deep - its pretty good and made with Unity, but one of there big moments was moving to Unity 5, there were quite a few revisions after that, to be honest, as a player I don’t really care (or understand) what that actually means, so why tell me? I want to know about the features and goodies that I am going to get in the update :slight_smile:

I’m sure you know all of this, just my take on things from a players perspective. From a developers perspective I may consider more about the frequency of my releases. Microsoft, whether you deem them to be good or bad, have a fairly well scheduled release for updates, our server maintenance was scheduled around it in fact. If you plan to release an update each month, ever two months, or every quarter that’s cool and will help control those rapidly accelerating version integers! :slight_smile:

Privacy & Terms