Skip to main content
gamedev.net
🔒 Locked

how does versioning go?

Started by r 4 replies 600+ views
Original Post
r
r
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
rad
Shannon Barber
Shannon Barber
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).
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Newfound Ajarn
Newfound Ajarn
Subversion?
VLAjarn: Cause it (linux) NEVER crashesMrPr0Grmer: lol ur wrongMrPr0Grmer: RedHat crashesVLAjarn: I'm saying good builds of linux
Lord Bart
Lord Bart
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
abeylin
abeylin
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:
0.0.0.1
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: 1.2.0.0
And if you finish the new version, make it: 2.0.0.0
If your changes are minor, and its not really a new release, make it: 1.3.0.0
etc.

Or do what Oracle does:
7.3.4
8.1.7
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).


http://www.anywherenotes.com - never lose another note again.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.