aries-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r785078 - in /websites/production/aries: ./ content/development/ReleaseProcessRequirements.html content/development/branches_and_modules.png content/development/release_by_module.png
Date Wed, 09 Feb 2011 14:56:03 GMT
Author: zoe
Date: Wed Feb  9 14:56:02 2011
New Revision: 785078

Discussion page

      - copied unchanged from r785077, websites/staging/aries/trunk/content/development/branches_and_modules.png
      - copied unchanged from r785077, websites/staging/aries/trunk/content/development/release_by_module.png
    websites/production/aries/   (props changed)

Propchange: websites/production/aries/
--- svn:mergeinfo (original)
+++ svn:mergeinfo Wed Feb  9 14:56:02 2011
@@ -1 +1 @@

Modified: websites/production/aries/content/development/ReleaseProcessRequirements.html
--- websites/production/aries/content/development/ReleaseProcessRequirements.html (original)
+++ websites/production/aries/content/development/ReleaseProcessRequirements.html Wed Feb
 9 14:56:02 2011
@@ -235,18 +235,51 @@
           <td height="100%" width="100%">
             <!-- Content -->
             <div class="wiki-content"><h1 id="release_process_requirements">Release
process requirements</h1>
-<p>This is a page to help with the discussion of the requirements of a release from
+<p>Up to release 0.3 of Aries we released all of the modules at once, along with a
set of samples which demonstrated how the Aries components could be used together.</p>
+<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>
 <table class="confluenceTable">
 <tr><th class="confluenceTh"> No. </th><th class="confluenceTh">
Description </th><th class="confluenceTh"> Met currently </th></tr>
 <tr><td class="confluenceTd">  1 </td><td class="confluenceTd"> Follows
OSGi semantic versioning</td><td class="confluenceTd"> No </td></tr>
 <tr><td class="confluenceTd">  2 </td><td class="confluenceTd"> Must
have a buildable source distribution </td><td class="confluenceTd"> Yes </td></tr>
 <tr><td class="confluenceTd">  3 </td><td class="confluenceTd"> Must
have release notes</td><td class="confluenceTd"> Yes </td></tr>
-<tr><td class="confluenceTd">  4 </td><td class="confluenceTd"> Must
be publicly announced </td><td class="confluenceTd">  </td></tr>
+<tr><td class="confluenceTd">  4 </td><td class="confluenceTd"> Must
be publicly announced </td><td class="confluenceTd"> Yes </td></tr>
 <tr><td class="confluenceTd">  5 </td><td class="confluenceTd"> An
easy way for users to download the bundles for a given component</td><td class="confluenceTd">
Yes </td></tr>
-<tr><td class="confluenceTd">  6 </td><td class="confluenceTd"> Easy
tagging/branching mechanism</td><td class="confluenceTd"> ? </td></tr>
+<tr><td class="confluenceTd">  6 </td><td class="confluenceTd"> Easy
tagging/branching mechanism</td><td class="confluenceTd"> Yes </td></tr>
 <tr><td class="confluenceTd">  7 </td><td class="confluenceTd"> A
way to provide bug fixes</td><td class="confluenceTd"> Yes  </td></tr>
 <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>
+<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.
+## 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. 
+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: 
+<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.
+<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>
             <!-- Content -->

View raw message