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:00:24 UTC
svn commit: r785085 -
/websites/staging/aries/trunk/content/development/ReleaseProcessRequirements.html
Author: buildbot
Date: Wed Feb 9 16:00:24 2011
New Revision: 785085
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:00:24 2011
@@ -284,7 +284,7 @@ at version 1.5.1 with blueprint-cm at 1.
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>
+<p>Other OSGi projects, for example Sling and Felix, release by bundle.</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>
@@ -293,9 +293,9 @@ and it works with blueprint-core 1.1.0.
</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>It is more difficult 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>Releasing - mvn release:prepare an so on, needs to be run for each bundle separately. 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 & 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>