3
\$\begingroup\$

When does a game version change

from x.x.x.x to x.x.x.x+1 like from 1.0.0.0 to 1.0.0.1

or from x.x.x.x to x.x.x+1.x ?

or from x.x.x.x to x.x+1.x.x ?

or from x.x.x.x to x+1.x.x.x ?

Should the first game version be 1.0.0.0 or 0.0.0.1?

\$\endgroup\$
3
  • \$\begingroup\$ This answer will help too: gamedev.stackexchange.com/questions/48325/… \$\endgroup\$
    – Lolums
    Sep 12 '15 at 17:05
  • \$\begingroup\$ This is very dependant on the developer. There is no "one reason" for that. \$\endgroup\$
    – Vaillancourt
    Sep 12 '15 at 18:36
  • \$\begingroup\$ Really, we should stick to one or two "Official" formats so that the users actually know what they mean. \$\endgroup\$
    – Lolums
    Sep 13 '15 at 7:52
2
\$\begingroup\$

What the accepted answer describes is called semantic versioning. It's a versioning scheme that describes how to version APIs, but it gives no guidelines on how to version applications (like video games). You can kind of hack it in, like this:

Increment MAJOR version for "major" changes
Increment MINOR version for "minor" changes
Increment PATCH version for bugfixes

But in general, there is no widely-adopted standard for application-versioning - everyone just plays it by ear.

So if you feel your update is big enough to warrant calling this "2.0", then do it; otherwise, increment one of the other numbers.

\$\endgroup\$
1
\$\begingroup\$

Pretty clearly this depends on the industry standard, but in web development, there is a move towards semantic versioning as a standard, which you can read about here:

http://semver.org/

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner, and

PATCH version when you make backwards-compatible bug fixes.

This isn't especially different from what Lolums is saying, but I wanted to give you a name for the process that will allow you to search for it in the future: semantic versioning

\$\endgroup\$
1
\$\begingroup\$

While there is no hard rules for software versions, the accepted (unofficial) standard these days is Semantic Versioning. Although the general meaning of the different version numbers has been used for a long time, how/when they are each incremented has been more of an art than a science. Semantic versioning is an attempt to make it more science and less art.

When does a game version change? (External Versioning)

The meaning of each version number is Major.minor.patch.critical

  • Major: Significant changes have been made. If the changes break compatibility with the previous version, you should certainly increment the Major version. Modifying the external API does not in itself demand a Major version change. If you add new classes/functions to the public API for example, it does not break compatibility so is not a Major version change. This is just a rule of thumb though. There are other good reasons to increment the Major version. You might increment the Major version number if there has been a large number of changes even though it remains backward compatible.
  • minor: Some changes have been made that affect the functionality of the software but do not warrant a Major increment. minor changes are always backward compatible.
  • patch: Non-critical bug fixes. Fixes which do not directly affect the functionality of the software. Eg. cosmetic changes, documentation updates, performance improvements
  • critical: Critical bug-fixes. These should be few but allows users to know when a version update is important. Critical bug-fixes would include fixing security issues, internal algorithms, broken installer, etc

To put it into more perspective: as an end-user when semantic versioning is used, one can tell when and if they should update to the latest version. If there is a critical update, then all users should update since it includes fixes for something that is fundamentally wrong with the software. Patch updates are less important fixes but should not break anything, so can (generally) be considered safe to update. Minor updates are less safe due to the amount of changes and introduction of new functionality but should be backward compatible. Each of these types of updates could introduce new bugs, which is why updating should be discretionary and not taken for granted. A major update should signify to the end-user that if they proceed with the update, they should expect to have some type of problems. Either having to migrate to the new version or changing something about how they use the software.

As to when to change version numbers (opposed to what version number to change): Only increment the version numbers when an update is released.

Internal Versioning

Internally, you should be using revision numbers that correspond to your version control software (svn, git, hg, etc), otherwise if you aren't using a VCS, you should increment the build number each time you build a new binary.

What this means is that if it takes you 500 revisions before you have something ready for release, your v1.0.0.0 package will be at rev500. Why, is because internally you need to keep track of every change but externally/publicly the end-user only cares about what has changed since the last release. As well, if you were to increment the version number internally, when you do release there could be large gaps in the version numbers which causes confusion.

What version number should you start at?

Prior to your first official public release, you will probably be releasing packages for testing purposes. These will start at v0.1.0.0 and will increment the same way as described above except you will not increment the Major version yet. The first major version (v1.0.0.0) will be the official, final release. Eg, when it's ready for sale.

Concerning games particularly, if you use semantic versioning then a sequel to the game is not a major update, it is an entirely new release and should start at v1.0.0.0 again, even if it's the 7th game in a series. Many games (and other software) do not follow this convention.

Whatever you do, I suggest you document how your version scheme works so that your end-users (and other developers) can understand what the numbers mean and utilize them appropriately.

\$\endgroup\$
1
  • \$\begingroup\$ "...Many games (and other software) do not follow this convention...." Visual Studio comes to mind perfectly, They've been incrementing the same msvc compiler version since 1983. \$\endgroup\$
    – Casey
    Sep 12 '15 at 20:16

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