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

[bu...@apache.org]

Author: buildbot
Date: Wed Feb  9 15:57:33 2011
New Revision: 785084

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 15:57:33 2011
@@ -253,18 +253,18 @@ 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>
 
-<p>Our ideal for a release process would involve to release by module, one might visualise the process like this: </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>
 <p>In this case, we have a module version (independent of the version of its sub-modules) and a set of sub-modules which may each be indepndently versioned.</p>
 
-<h2 id="advantages_of_release_by_module">Advantages of release by module</h2>
+<h3 id="advantages_of_release_by_module">Advantages of release by module</h3>
 <ol>
 <li>Releasing a coherent set of bundles that have been built and run together</li>
 <li>Releasing a buildable set of source for all constituent bundles in one zip file</li>
 <li>A more consumable unit than a set of single bundles - easier for Aries consumers. A smaller number of discrete downloads.</li>
 </ol>
-<h2 id="disadvantages_of_the_release_by_module_process">Disadvantages of the release by module process</h2>
+<h3 id="disadvantages_of_the_release_by_module_process">Disadvantages of the release by module process</h3>
 <ol>
 <li>We would want to release a whole module at once, this would mean re-releasing bundles at the same level 
  (and with the same content) as a previous release. This is not a major issue</li>
@@ -282,6 +282,23 @@ the major version. Another release of bl
 <p>Meanwhile a customer finds a problem in blueprint module version 1.5 in the blueprint-cm module. They would like a release of the blueprint module
 at version 1.5.1 with blueprint-cm at 1.0.3. Unfortunately this is impossible because we have already released blueprint-cm at 1.0.3
 and it works with blueprint-core 1.1.0. So, we have no way to meet the requirement </p></li>
+</ol>
+<h2 id="releasing_by_bundle">Releasing by bundle</h2>
+<p>Other OSGi projects, for example Sling and Felix, release by module.</p>
+<h3 id="advantages_of_releasing_by_bundle">Advantages of releasing by bundle</h3>
+<ol>
+<li>Other projects already do it so there is a well understood model</li>
+<li>All the existing tools work</li>
+<li>OSGi semantic versioning can be used properly</li>
+</ol>
+<h3 id="disadvantages_of_releasing_by_bundle">Disadvantages of releasing by bundle</h3>
+<ol>
+<li>It is more dificult for a consumer of Aries modules to understand which bundles form a logical grouping</li>
+<li>There are a lot of bundles to manage independently. This has implications:</li>
+<li>Releasing - mvn release:prepare an so on,  needs to be run for each bundle seperately. However, many bundles could be rolled up into one vote.</li>
+<li>Each bundle has to have its own JIRA component</li>
+<li>Our svn tree would need to be restructured - probably in a similar way to the Sling tree. Each bundle would have its own trunk &amp; branches.</li>
+<li>There are still some issues with branching and it is still possible to get into a situation similar to that described above. </li>
 </ol></div>
             <!-- Content -->
           </td>