Does anyone know if there's a best practice for labeling game versions.

I'm not sure if there's a standard name for it other than versioning but what I mean is basically:

  • 1.0
  • 1.1
  • 1.2
  • 1.3.1 beta

4 Answers 4


There is no standard, but you should do it in a way that makes sense to you and contains all the information you may need to track that build. I worked for a company that essentially broke it down like this:

[Major build number].[Minor build number].[Revision].[Package]

i.e. Version:

  • Major build number: This indicates a major milestone in the game, increment this when going from beta to release, from release to major updates.

  • Minor build number: Used for feature updates, large bug fixes etc.

  • Revision: Minor alterations on existing features, small bug fixes, etc.

  • Package: Your code stays the same, external library changes or asset file update.

Combined changes roll over to the most significant change. For example, if you're incrementing the minor build number, the revision and package both reset to 0.

Even though the categories are defined, there's still ambiguity for what kind of features actually cross over between a revision and a minor build number. It's up to you. If you make lists of the features that will need to be implemented before each increment, you'll also have a plan to follow, but in the end it's your decision as to what fits into each category.

  • 1
    \$\begingroup\$ That's awesome information, everywhere I looked it only talked about Major ad minor build numbers with no real explanation as to what falls into each. \$\endgroup\$ Commented Jan 29, 2013 at 16:01
  • \$\begingroup\$ semver.org \$\endgroup\$
    – Kzqai
    Commented Sep 12, 2015 at 17:55

Stack Overflow has a great discussion on this called How To Do Version Numbers, which references the Versioning Style Guide.


  • MAJOR version when you make incompatible API changes
  • MINOR version when you add functionality in a backwards-compatible manner
  • PATCH version when you make backwards-compatible bug fixes
  • Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format
  • 1
    \$\begingroup\$ While this is totally true for libraries, the semantics of this versioning become merely irrelevant when applied to games imho (unless you provide a mod API, maybe). \$\endgroup\$
    – Paul K
    Commented Mar 24, 2021 at 6:51

As far as I know, there is no standard for that. Practice will vary depending on companies, teams and projects: there is no such thing as a best practice. The most important thing is not the actual convention, but the fact that everyone sticks to it.

That said, the scheme you mentioned is quite common for released games. 1.0 will typically be the gold master, and patches will start from there: 1.1, 1.2... It'as also used in pre-release customer versions such as private or open betas.

For games in development I've rarely seen this system used. It is much more common to refer to a build by its atomic change ID (e.g. Perforce changelist number). This is particularly useful for a middle-scale project where everything (code & assets) is stored on the same repository, and continuous integration is in place. In this case, having both an atomic change number and a version number is redundant and error prone. Some builds will be promoted to a milestone after QA: alpha, beta, release candidate, and labelled as such.

For big projects, the simple concept of a "game version" doesn't apply anymore. You'll have several platforms, SKUs, languages, single-player mode, multi-player mode, etc. Managing versions becomes then a full-time job (sometimes called a data manager -- this is Ubisoft terminology, probably called differently elsewhere), the labeling scheme is then much more complex and highly dependant on the actual game being made.

  • \$\begingroup\$ wow, it becomes a job in itself? I always thought the leads of each department would manage it's own versioning. \$\endgroup\$ Commented Jan 29, 2013 at 16:03
  • 2
    \$\begingroup\$ @ChaoticLoki You need proper coordination between departments to make sure that, for instance, level designers are working on the latest stable executable. Or that programmers can find who screwed up a variable in the localized text (as in : "The Italian translator fixed dialog X, accidentally broke tutorial text Y at the same time, but we can't revert to the old version because the exe isn't compatible. Arghhh! Help?"). And so on. In a big team, you need somebody to take care of all this. It's actually one of the most challenging jobs in the industry. \$\endgroup\$ Commented Jan 29, 2013 at 16:26

Game Versions Really depend on how you want to use it like 1.0.2021 or maybe It can mean different things depending on the company/small team/person that created the game.

  • 1
    \$\begingroup\$ You could improve this answer by explaining why 1.0.2021 or are good version numbers or what "different things" could contribute to a version number and how that affects/improves the version number as opposed to not including them :) \$\endgroup\$ Commented Mar 24, 2021 at 17:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .