   Version Numbering
  I was just wondering how you set the version for your software. How much does it take before i becomes 2.0?When is it a just a new build if 1.0 an when is it 1.0.1?Stuff like that. I would really like to know. 
  At my last job, which was a networked client/server system, we used the X.Y.Z numbering system.The major version number (X) represents an architectural revision, typically meaning that backwards compatibility is broken.The minor version number (Y) is a feature within an architectural revision, always maintaining backwards compatibility.Finially, the last number (Z) is a maintenance indicator, representing a maitnenance release of the same feature set. By default, the last number is left off (i.e. v3.1, not v3.1.0), unless it is an acutal maintenance release (i.e. v3.1.1 or v3.1.2).While this sounds logical, sometimes it is overridden by marketing types (one version of our software should have been 1.4, but for marketing reasons was released as 2.0).;APR Versioning Guidelines --AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [Blog] [RSS] [Browse the source] [IRC channel] ;  Hello tordyvel,At work we had a X.X.X version but then we switch to an X.X.X.X.were like what AP stated first number major changes no backward compatibilitynext minor additions to interface.then release number and last private build number.We went this way because we were releasing builds that did not follownumber wise using X.X.X. ie 2.0.4 then a 2.0.12 etc bad if customer gets a new release and number change that much.Now they get 2.0.20 2.0.21 etc with private build number just that for private build not released and get reset for each release. ie. actual release was 2.0.20.14and 2.0.21.0 which would have been 2.0.20.15.Plus try to keep marketing/busness people form changing realease number on you unless they have a very vaild and logical reason to do so, and then it should not be done at all, well they could have a point once in a while.Lord Bart 