You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@aries.apache.org by zo...@apache.org on 2011/03/15 10:38:53 UTC

svn commit: r786991 - in /websites/production/aries: ./ content/development/versionpolicy.html

Author: zoe
Date: Tue Mar 15 09:38:53 2011
New Revision: 786991

Log:
draft bundle versioning scheme

Modified:
    websites/production/aries/   (props changed)
    websites/production/aries/content/development/versionpolicy.html

Propchange: websites/production/aries/
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Mar 15 09:38:53 2011
@@ -1 +1 @@
-/websites/staging/aries/trunk:782169-786967
+/websites/staging/aries/trunk:782169-786990

Modified: websites/production/aries/content/development/versionpolicy.html
==============================================================================
--- websites/production/aries/content/development/versionpolicy.html (original)
+++ websites/production/aries/content/development/versionpolicy.html Tue Mar 15 09:38:53 2011
@@ -250,8 +250,13 @@ During development, in trunk, the Maven 
 <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
+<p><strong>EITHER</strong>
+At release time the release version of the bundle must be assigned by the release manager after reviewing
 the changes to the bundle's package versions since the last release.</p>
+<p><strong>OR</strong>
+Whenever a developer makes a change to a package version they must check the bundle version and, if necessary, modify the bundle
+version in line with changes that have been made to packages. In this case the RM has no
+additional work - correct bundle semantic versioning is the responsibility of the developer making the code changes</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 
@@ -270,10 +275,17 @@ recent release of the package and not to
 <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>
+<li>Developer A adds a method to an interface in the package and increments it's version to a.b+1.0</li>
+<li>
+<p>Developer B fixes a bug in the package, leaves its version at a.b+1.0</p>
+</li>
+<li>
+<p>Scenario 3, making changes to a package with released version a.b.c</p>
+</li>
+<li>Developer A fixes a bug in the package, and increments its version to a.b.c+1</li>
+<li>Developer B deletes a method from an interface and increases the package version to a+1.0.0</li>
 </ul>
-<h2 id="importing_packages">Importing packages</h2>
+<h3 id="importing_packages">Importing packages</h3>
 <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