svn commit: r779078 - /websites/staging/river/trunk/content/development-process.html

[bu...@apache.org]

Author: buildbot
Date: Thu Nov 11 11:51:28 2010
New Revision: 779078

URL: http://svn.apache.org/viewvc?rev=779078&view=rev
Log:
Staging update by buildbot

Modified:
    websites/staging/river/trunk/content/development-process.html

Modified: websites/staging/river/trunk/content/development-process.html
URL: http://svn.apache.org/viewvc/websites/staging/river/trunk/content/development-process.html?rev=779078&r1=779077&r2=779078&view=diff
==============================================================================
--- websites/staging/river/trunk/content/development-process.html (original)
+++ websites/staging/river/trunk/content/development-process.html Thu Nov 11 11:51:28 2010
@@ -106,21 +106,23 @@ The preferred place of discussion on iss
 <p>Developing test cases and running test suites are desired but not required prior to an integration.  If unit tests are created for a change, the developer is encouraged to add them to the JIRA issue for sharing.</p>
 <h2 id="version_numbering">Version Numbering</h2>
 <p>Each Apache River deliverable has a version number of:</p>
-<p>{{m.n.r}}</p>
-<p>{{m}} = major version
-  {{n}} = minor version
-  {{r}} = maintenance version</p>
+<p><code>m.n.r</code></p>
+<ul>
+<li><code>m</code> = major version</li>
+<li><code>n</code> = minor version</li>
+<li><code>r</code> = maintenance version</li>
+</ul>
 <p>The major version number will in general only be increased in case of major changes that might introduce compatibility problems or represent some fundamental improvements. The minor versions reflect the various feature releases, the last part of the version number reflects the maintenance release.</p>
 <h2 id="branching_policy">Branching Policy</h2>
-<p>Ongoing development for the next release takes place in the {{/trunk}}. Once feature complete for a (non maintenance) release the trunk is branched into {{/branches/<m.n>}} which in general also reflects the moment a release candidate is presented to the public in a fairly short period of time. Ongoing development continues in the {{/trunk}}, issues found against the release candidate will be fixed in {{/branches/<m.n>}} and likely merged into the {{/trunk}}.</p>
-<p>Once a release candidate is ready for a first customer release {{/branches/<m.n>}} is branched into {{/tags/<m.n>.0}}. When support is required for a particular release {{m.n}}, the development for a fix-release is conducted in {{/branches/<m.n>}}. When a bug-fix release is ready it is branched into {{/tags/<m.n.r>}} where {{r}} is a positive number and increased for each maintenance release.</p>
-<p>Although ongoing development should take place in {{/trunk}}, there is a {{/skunk}} branch that can be utilized for 'experimental' work that must not disturb the {{/trunk}}, that needs to be visible to others and/or might require participation of others. In general the lifetime of such branch should be short to give it a chance of successful integration into the {{/trunk}} when the 'experiment' has been found valuable.</p>
+<p>Ongoing development for the next release takes place in the <code>/trunk</code>. Once feature complete for a (non maintenance) release the trunk is branched into <code>/branches/&lt;m.n&gt;</code> which in general also reflects the moment a release candidate is presented to the public in a fairly short period of time. Ongoing development continues in the <code>/trunk</code>, issues found against the release candidate will be fixed in <code>/branches/&lt;m.n&gt;</code> and likely merged into the <code>/trunk</code>.</p>
+<p>Once a release candidate is ready for a first customer release <code>/branches/&lt;m.n&gt;</code> is branched into <code>/tags/&lt;m.n&gt;.0</code>. When support is required for a particular release <code>m.n</code>, the development for a fix-release is conducted in <code>/branches/&lt;m.n&gt;</code>. When a bug-fix release is ready it is branched into <code>/tags/&lt;m.n.r&gt;</code> where <code>r</code> is a positive number and increased for each maintenance release.</p>
+<p>Although ongoing development should take place in <code>/trunk</code>, there is a <code>/skunk</code> branch that can be utilized for 'experimental' work that must not disturb the <code>/trunk</code>, that needs to be visible to others and/or might require participation of others. In general the lifetime of such branch should be short to give it a chance of successful integration into the <code>/trunk</code> when the 'experiment' has been found valuable.</p>
 <p><em>Summarized</em></p>
 <p>||branch||description||
-|{{.../river/<product>/trunk}}|mainline development|
-|{{.../river/<product>/branches}}|maintenance branches|
-|{{.../river/<product>/tags}}|frozen release tags|
-|{{.../river/<product>/skunk}}|development and 'skunk works' branches|</p>
+|<code>.../river/&lt;product&gt;/trunk</code>|mainline development|
+|<code>.../river/&lt;product&gt;/branches</code>|maintenance branches|
+|<code>.../river/&lt;product&gt;/tags</code>|frozen release tags|
+|<code>.../river/&lt;product&gt;/skunk</code>|development and 'skunk works' branches|</p>
 <pre>
 /trunk
    |