<p>Our situation is as follows, but I'm curious about this problem in any situation.</p>

<p>We have a framework consisting of 4 projects:</p>

<ul>
<li>beans</li>
<li>util</li>
<li>framework</li>
<li>web</li>
</ul>

<p>We also have modules that need a version and depend on a version of beans and util.</p>

<p>Finally we have a customer project that consists of a specific version of the core projects and one or more modules.</p>

<p>Is there a standard way to version these projects?</p>

<p>What seems simple to me is becoming really complicated as we try to deliver releases to QA and then manage our ongoing development with the maintenance of the release (release = tag and possible branch).</p>

<p>I kind of prefer the following:</p>

<p>1.2.0 - major and minor versions + release.</p>

<p>1.2.1 - next release</p>

<p>1.2.0_01 - bug fix in 1.2.0 release (branch)</p>

<p>etc.</p>

<p>Any ideas?</p>

There are no standard version number systems. Common themes are to have a major, minor and build number, and occasionally a point number as well (1.2.2.1 for example, for version 1.2 point release 2 build 1). The meaning of the version numbers is highly flexible. A frequent choice is to have backwards compatibility between minor versions or point releases though.
Releases are probably best done by labeling a set of source controlled files as long as your source control allows this. Recreating a release is then as simple as syncing to the label and building, which is very useful :)