Version numbers - what do they mean?
There are a number of standard version numbering schemes (such as Semantic Versioning) in widespread use, which can cause confusion as to what exactly each part of a version number means. Although semver is a nice scheme, especially for open source libraries that require backwards-compatibility and interoperability with other software, for our games we prefer a more detailed version scheme.
Here are some examples of our current game versions:
- AdvertCity: 9.6.9482.51853
- GolfXTRM: Beta 3.9.3190.17368
- Fractyr: Alpha 2.3.1411.7511
- sphereFACE: Beta 6.5.6005.33140
- TacWing: Alpha 4.1.3448.18916
The format of our builds is Status Major.Minor.Build.Revision.
- Status may be Alpha, Beta, RC1,2,3 etc or blank in the case of a finished release.
- Revision is incremented whenever there are any changes made to the code.
- Build is incremented every time code is changed and a new successful build is completed.
- Minor version is automatically incremented after every 100 builds.
- Major is automatically incremented every ten minor versions, so our major number rises once per every thousand successful new builds.
Alpha, Beta and release
Status is currently Beta for sphereFACE; before its Kickstarter, it was on Alpha. When we make our final release we'll just drop this prefix from the version numbers, like in AdvertCity. Although "Gold" is one industry standard for a final release version name, we think it sounds kind of awkward. Another common standard is "Final", but that is misleading since we'll still be making bug fixes and incremental improvements once the game is released. Instead we just drop the prefix entirely, and work with numbers only in the versions of our public releases.
Once we're running up to the end of a Beta, we release a special version called a Release Candidate, where all features are fixed, and the only changes before release will be bug fixes - this will get the suffix RC1, and these will be rapidly re-released and incremented until there are no more discovered bugs, and the game is ready for its official release to the public.
The revision is incremented whenever there are any changes made to the code. That means every time there's any modification, regardless of whether the code compiles successfully or not, this number is incremented. Every time a change in any file is saved, this number is incremented, but it does not map to a new release of the program.
The build number is incremented only when code is changed and a new successful build is completed - i.e. when a game is compiled from source to a binary. This isn't incremented if there are compilation errors, nor is it incremented if the same code is recompiled without changes, so each represents a unique and working build.
If a program is re-built without any changes made to the codebase, no change occurs to the version number.
Manually keeping track of version numbers is time consuming and error-prone, so we use an auto-versioning plugin in our IDE of choice, which is Code::Blocks (it's free, open-source, works on Windows and Linux and OS X).
This can be configured to increment major and minor numbers the way we prefer, and automatically tracks both revisions and builds separately.