svn commit: r786961 - /websites/staging/aries/trunk/content/development/versionpolicy.html

[bu...@apache.org]

Author: buildbot
Date: Mon Mar 14 14:32:24 2011
New Revision: 786961

Log:
Staging update by buildbot

Modified:
    websites/staging/aries/trunk/content/development/versionpolicy.html

Modified: websites/staging/aries/trunk/content/development/versionpolicy.html
==============================================================================
--- websites/staging/aries/trunk/content/development/versionpolicy.html (original)
+++ websites/staging/aries/trunk/content/development/versionpolicy.html Mon Mar 14 14:32:24 2011
@@ -234,30 +234,50 @@
           </td>
           <td height="100%" width="100%">
             <!-- Content -->
-            <div class="wiki-content"><p>Versioning policy - DRAFT</p>
-<p>This projecst aims to implement OSGi semantic versioning as described here: www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf.</p>
+            <div class="wiki-content"><h1 id="versioning_policy_-_draft">Versioning policy - DRAFT</h1>
+<p>The Aries  project aims to implement OSGi semantic versioning as described <a href="www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf">here</a>.</p>
 <p>The implementation of semantic versioning has a number of practical implications for managing a project. These are
 outlined in this section. </p>
-<p>Bundle version.
-OSGi semantic versioning applies to bundles as well as packages. When releaseing a new version of a bundle
+<h2 id="bundle_versions">Bundle versions</h2>
+<p>OSGi semantic versioning applies to bundles as well as packages. When releasing a new version of a bundle
 the change in the bundle version should give some indication of nature of the changes to the bundle.
-In Aries the bundle version is always the same as version of the Maven artifact that relates to the bundle. 
-During development teh Maven artifact version may be either:</p>
+In Aries the bundle version is the same as version of the Maven artifact version. 
+During development, in trunk, the Maven artifact version may be:</p>
 <ul>
-<li>x.y.z Where x.y.z is the most recent release of the bundle</li>
-<li>x.y.(z+1)-SNAPSHOT Indicating that the bundle has changed since it was last released.</li>
+<li>either x.y.z Where x.y.z is the most recent release of the bundle</li>
+<li>or x.y.(z+1)-SNAPSHOT Indicating that the bundle has changed since it was last released.</li>
 </ul>
-<p>Immediately after a release the Maven version is  set the same as the release. Bundles which depend
+<p>Immediately after a release the Maven version is set the same as the release. Bundles which depend
 on the bundle will pick up the released version. When a developer first makes a change to the bundle the version
 is changed to be a SNAPSHOT version, indicating to a release manager that the bundle is a candidate for release.</p>
 <p>At release time the release version of the bundle must be assigned by the release manager after reviewing
-the changes since the last release.</p>
-<p>Package versions</p>
-<p>Exported packages
-Versions specified in packageinfo files with teh source code.
-The location of pacgageinfo is configured in build resounces in the default-parent pom. If your pom has a build resources section it replaces what is inherited from teh default-parent, so you may need to reproduce the section which specifies where packageinf can be found.</p>
-<p>Imports
-The bnd defualt verion range policy for imports is teh consumer policy (==, +), you may need to override this if you want to be more prescriptove about secific aries imports.</p></div>
+the changes to the bundle's package versions since the last release.</p>
+<h2 id="package_versions">Package versions</h2>
+<h3 id="exported_packages">Exported packages</h3>
+<p>Versions are usually specified in packageinfo files with the source code. The default-parent pom is 
+configures (in the build resources section) to expect packageinfo files. If your pom has a build
+resources section it replaces what is inherited from the default-parent, so you may need to reproduce 
+the section which specifies where packageinfo can be found.</p>
+<p>Developers <strong>must</strong> increment the versions in packageinfo files in strict accordance with OSGi
+semantic versioning when they make changes to a package. The version should relate to the most
+recent release of the package and not to the version found in trunk. For example:</p>
+<ul>
+<li>Scenario 1, making changes to a package with released version a.b.c</li>
+<li>Developer A fixes a bug in the package and increments it's version to a.b.c+1</li>
+<li>
+<p>Developer B fixes another bug in the package but leaves the version at a.b.c+1 </p>
+</li>
+<li>
+<p>Scenario 2, making changes to a package with released version a.b.c</p>
+</li>
+<li>Developer A fixes a bug in the package and increments it's version to a.b.c+1</li>
+<li>Developer B makes an API breaking change and increases the package version to (a+1).0.0</li>
+</ul>
+<h2 id="importing_packages">Importing packages</h2>
+<p>The bnd default version range policy for imports is the consumer policy (==, +), you may need to 
+override this if you want to be more prescriptive about specific Aries imports.
+The policy can be set by using the Maven property <aries.osgi.version.policy>, see the default-parent
+pom for an example.</p></div>
             <!-- Content -->
           </td>
         </tr>