aries-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r799115 - /websites/staging/aries/trunk/content/development/versionpolicy.html
Date Tue, 22 Nov 2011 17:47:27 GMT
Author: buildbot
Date: Tue Nov 22 17:47:26 2011
New Revision: 799115

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 Tue Nov 22 17:47:26
2011
@@ -292,13 +292,17 @@ the change in the bundle version should 
 In Aries the bundle version is the same as version of the Maven artifact version. 
 During development, in trunk, the Maven artifact version will be:</p>
 <ul>
-<li>either x.y.(z+1)-SNAPSHOT </li>
+<li>x.y.(z+1)-SNAPSHOT </li>
 </ul>
 <p>Where x.y.z is the most recent release of the bundle</p>
-<p>During the release process release Maven version is set to a minor increment of
the release version by default. </p>
-<p>For example, if proxy is released at version 1.0.0, the development version of proxy
in trunk will become 1.0.1.</p>
-<p>Bundles which depend on proxy (for example blueprint) will be set to depend on the
released version of proxy, so for example, immediately after 
-a release of proxy at 1.0.0 and a release of blueprint at, say, 1.2.0, the development version
of blueprint in trunk will be 1.2.1-SNAPSHOT
+<p>During the release process the Maven release plugin asks for a the subsequent version
to use in the module's pom after the release has taken place. The default is to increment
the last digit and add -SNAPSHOT.</p>
+<p>For example, if proxy is released at version 1.0.0, the development version of proxy
in trunk will become 1.0.1-SNAPSHOT.</p>
+<p>In addition, after a release, modules dependencies should refer to the lowest
+released version providing enough exported functionality the bundle
+requires. This ensures the import version is automatically set correctly
+to allow for loose coupling supported by OSGi.</p>
+<p>For example, bundles which depend on proxy (e.g. blueprint) will be set to depend
on the released version of proxy. Immediately after 
+a release of proxy at say 1.0.0 and a release of blueprint at 1.2.0, the development version
of blueprint in trunk will be 1.2.1-SNAPSHOT
 but the version of proxy that it depends on will be 1.0.0.</p>
 <h3 id="assigning_a_bundle_version_number_at_release_time">Assigning a bundle version
number at release time</h3>
 <p>At release time the release version of the bundle must be assigned by the release
manager after reviewing



Mime
View raw message