 <p>In my opinion, almost any release number scheme can be made to work more or less sanely. The system I work on uses version numbers such as 11.50.UC3, where the U indicates 32-bit Unix, and the C3 is a minor revision (fix pack) number; other letters are used for other platform types. (I'd not recommend this scheme, but it works.)</p> <p>There are a few golden rules which have not so far been stated, but which are implicit in what people have discussed.</p> <ul> <li>Do not release the same version twice - once version 1.0.0 is released to anyone, it can never be re-released.</li> <li>Release numbers should increase monotonically. That is, the code in version 1.0.1 or 1.1.0 or 2.0.0 should always be later than version 1.0.0, 1.0.9, or 1.4.3 (respectively).</li> </ul> <p>Now, in practice, people do have to release fixes for older versions while newer versions are available -- see GCC, for example:</p> <ul> <li>GCC 3.4.6 was released after 4.0.0, 4.1.0 (and AFAICR 4.2.0), but it continues the functionality of GCC 3.4.x rather than adding the extra features added to GCC 4.x.</li> </ul> <p>So, you have to build your version numbering scheme carefully.</p> <p>One other point which I firmly believe in:</p> <ul> <li>The release version number is unrelated to the CM (VCS) system version numbering, except for trivial programs. Any serious piece of software with more than one main source file will have a version number unrelated to the version of any single file.</li> </ul> <p>With SVN, you could use the SVN version number - but probably wouldn't as it changes too unpredictably.</p> <p>For the stuff I work with, the version number is a purely political decision.</p> <p>Incidentally, I know of software that went through releases from version 1.00 through 9.53, but that then changed to 2.80. That was a gross mistake - dictated by marketing. Granted, version 4.x of the software is/was obsolete, so it didn't immediately make for confusion, but version 5.x of the software is still in use and sold, and the revisions have already reached 3.50. I'm very worried about what my code that has to work with both the 5.x (old style) and 5.x (new style) is going to do when the inevitable conflict occurs. I guess I have to hope that they will dilly-dally on changing to 5.x until the old 5.x really is dead -- but I'm not optimistic. I also use an artificial version number, such as 9.60, to represent the 3.50 code, so that I can do sane <code>if VERSION &gt; 900</code> testing, rather than having to do: <code>if (VERSION &gt;= 900 || (VERSION &gt;= 280 &amp;&amp; VERSION &lt; 400)</code>, where I represent version 9.00 by 900. And then there's the significant change introduced in version 3.00.xC3 -- my scheme fails to detect changes at the minor release level...grumble...grumble...</p> <p><em>NB</em>: Eric Raymond provides <a href="http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/naming.html" rel="nofollow noreferrer">Software Release Practice HOWTO</a> including the (linked) section on naming (numbering) releases.</p>