Author: buildbot
Date: Wed Feb 9 15:05:15 2011
New Revision: 785080
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:05:15 2011
@@ -239,7 +239,7 @@
<p>After release 0.3 we wanted to rexamine the release process, the primary
motivation for this was the observation that our
current process did not use semantic versioning, and, as an OSGi project we
should be demonstrating best OSGi practice.</p>
-<p>We started with the following set of requirements for any Aries release:
+<p>We started with the following set of requirements for any Aries release:
</p>
<table class="confluenceTable">
<tr><th class="confluenceTh"> No. </th><th class="confluenceTh"> Description
</th><th class="confluenceTh"> Met currently </th></tr>
@@ -253,36 +253,36 @@ 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>Our ideal for a release process would involve to release by module, one
might visualise the process like this: </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>
-<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.
-
-## Advantages of release by module
-
-1. Releasing a coherent set of bundles that have been built and run together
- 1. Releasing a buildable set of source for all constituent bundles in one zip
file
- 1. A more consumable unit than a set of single bundles - easier for Aries
consumers. A smaller number of discrete downloads.
-
-## Disadvantages of the release by module process
-
-1. 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
- 1. Developer would need to be careful to version submodules poms
independently from the parent/reactor pom. Again,
- not a major issue but a change from the way we work at the moment.
- 1. The Maven release plugin will not cope with having different levels of
snapshot in the same release.
+<h2 id="advantages_of_release_by_module">Advantages of release by module</h2>
+<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>
+<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>
+<li>Developer would need to be careful to version submodules poms
independently from the parent/reactor pom. Again,
+ not a major issue but a change from the way we work at the moment.</li>
+<li>The Maven release plugin will not cope with having different levels of
snapshot in the same release.
Therefore we would either require changes in the Maven release plugin or we
would have to stop using it
-and maintain our own alternative, to allow us to release by module.
- 1. It's not all clear what the strategy for branching would be. For example,
consider the following scenario:
-
+and maintain our own alternative, to allow us to release by module.</li>
+<li>It's not all clear what the strategy for branching would be. For example,
consider the following scenario:
+<img alt="rel" src="branches_and_modules.png" />
<p>The bundles in trunk should be versioned differently from the versions in
branch. This really mandates a bump in the major version.
<p>The consequence of not bumping the major version and using the versioning
tool to compare versions in trunk (for the next release from trunk)
and using the versioning tool to create bug fix versions from the branch has
the potential to lead to the situation in which bundles with the
-same version number have different content.
+same version number have different content.</p>
<p>For example, as time goes on another release (version 6) of the proxy
module is created, the version compare tool dictates that proxy-impl
should be released at version 0.4.2. But now, someone who wants a fix to
proxy-impl in 0.4.1 (in proxy module version 5) which would be provided
-from the branch, would also get a proxy-impl bundle at version 0.4.2 with
different content. This is a situation which must be avoided.</div>
+from the branch, would also get a proxy-impl bundle at version 0.4.2 with
different content. This is a situation which must be avoided.</p></li>
+</ol></div>
<!-- Content -->
</td>
</tr>
