how does versioning go?
Author
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
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).
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).
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
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
APR''s Version Numbering.
And yes, Subversion.
--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]
And yes, Subversion.
--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
