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

Link to post

Share on other sites

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

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.

Share this post

Link to post

Share on other sites

At work we use it as following:first number: major releasesecond number: patch or release has to be rebuild because bug was found in QAthird number: major modification to the code, but not yet major releasefourth 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.1When 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.0And if you finish the new version, make it: 2.0.0.0If your changes are minor, and its not really a new release, make it: 1.3.0.0etc.

Or do what Oracle does:7.3.48.1.79i (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).