You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@aries.apache.org by bu...@apache.org on 2011/02/09 17:47:54 UTC

svn commit: r785094 - /websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html

Author: buildbot
Date: Wed Feb  9 16:47:54 2011
New Revision: 785094

Log:
Staging update by buildbot

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

Modified: websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html
==============================================================================
--- websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html (original)
+++ websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html Wed Feb  9 16:47:54 2011
@@ -253,6 +253,20 @@ current process did not use semantic ver
 <tr><td class="confluenceTd">  8 </td><td class="confluenceTd"> A way to ensure that a given component doesn't have conflicting dependencies </td><td class="confluenceTd"> ?  </td></tr>
 </table>
 
+<h2 id="release_all_aries_components_at_once">Release all Aries components at once.</h2>
+<h3 id="advantages_of_releasing_everything_at_once_and_at_the_same_level">Advantages of releasing everything at once and at the same level</h3>
+<ol>
+<li>Conceptually very simple of consumers. For example, if as a consumer I pick up something called Blueprint version 0.4 I know that I
+will need to get Util version 0.4 to go with it.</li>
+<li>A relatively simple release process, one JIRA component, one set of release notes.i</li>
+<li>We can release a set of samples at the same version with some guarentee that the samples all work with the release.</li>
+</ol>
+<h3 id="disadvantages_of_releasing_everything_at_once">Disadvantages of releasing everything at once</h3>
+<ol>
+<li>Not using of OSGi semantic versioning of bundles.i After every we release we bump the major versions of all bundles in trunk.</li>
+</ol>
+<p>Package versions are managed separately and the Maven bundle plugin will ensure packges are imported in the correct range based of
+ the projects dependencies. Implementors need to use "provide:=true" to get the correct range. Package export version should be maintained either using package.info or in the pom.</p>
 <h2 id="releasing_by_module">Releasing by module</h2>
 <p><p>Our ideal for a release process would involve to release by module, one might visualise the process like this: </p></p>
 <p><img alt="rel" src="release_by_module.png" /></p>