Advertisement Jump to content


This topic is now archived and is closed to further replies.


how does versioning go?

This topic is 5484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, i want to know how version numbers work, for example do u start with a 0.01 and still increment the fraction part till u have a bugs-free beta ? also is there any famous conventions and how do they go with alpha and beta phases? for example if while i was working i found a small bug and i corrected it, should i increment the version number so that the team knows or what?, and also is there are anything beside alpha and beta versions? all i know is that an alpha is a non-feature complete(in progress) version of what u r doing, and a beta is a non-bugs free, feature complete of the product, so plz correct me if i''m wrong or incomplete. thanx alot for ur time

Share this post

Link to post
Share on other sites
Alpha, Beta, Release Candidate(s), Gold

Beta doesn''t have to be feature complete, but a release candidate ought to be.

I''ve seen versioning done many different ways.

You should probably use some software to help you track versions. CVS is free (search for CVSNT for a Win32 version) and I can''t remeber the one Arlid Fines always suggest (it''s suspose to be better than CVS).

Share this post

Link to post
Share on other sites
Hello r,

At work we follow a 4 number versioning system (X.XX.XX.XX)
first number major release number changes only when big change occurs, like underlying engine/database changes.
next number minor number for when were added a component.
added a new process/feature.
next number release number incremented for each outside release.
This goes to outside world to use.
last number is private build number increment each full private build.

We build complete builds nightly(well almost) which gets every bodies changes/fixes for the day, we track what went in to each build.

We use clearcase, but you should use want ever file/project control software you have.

Lord Bart

Share this post

Link to post
Share on other sites
Yes, 4 numbers is good.

At work we use it as following:
first number: major release
second number: patch or release has to be rebuild because bug was found in QA
third number: major modification to the code, but not yet major release
fourth number: windows specific modification (all code is first done on Unix, if Windows port includes code modifications, this number is changed) ... but nightly builds is a better use for this number.

So I am assuming that if you want to use this for in house, start with:
When you first release your software, make it:
1.a.b.c (where a, b, c is between 0 and 99, but preferably all zeros)
If you need to issue a patch for release for that version, make it:
1.1.a.b (where this a and b have no relasion to a and b from the first example).
As you are working on second version of your program, modify the third position for anything bigger than a bug fix, and fourth position for minor things you change.

At this point if you need to issue a patch, release:
And if you finish the new version, make it:
If your changes are minor, and its not really a new release, make it:

Or do what Oracle does:
9i (i for I don''t remember what)
10g (g for Grid computing)

Or do what Microsoft does for their database, make up some number like 1.4324353459080384, and then say that that number is release 2 patch 3 (based on nothing in the version number itself). - never lose another note again.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!