aries-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From z..@apache.org
Subject svn commit: r1068924 - /aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext
Date Wed, 09 Feb 2011 15:05:11 GMT
Author: zoe
Date: Wed Feb  9 15:05:11 2011
New Revision: 1068924

URL: http://svn.apache.org/viewvc?rev=1068924&view=rev
Log:
para fixes

Modified:
    aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext

Modified: aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext
URL: http://svn.apache.org/viewvc/aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext?rev=1068924&r1=1068923&r2=1068924&view=diff
==============================================================================
--- aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext (original)
+++ aries/site/trunk/content/development/ReleaseProcessRequirements.mdtext Wed Feb  9 15:05:11
2011
@@ -4,7 +4,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>
@@ -18,11 +18,11 @@ 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>
 
 ![rel](release_by_module.png)
 
-<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>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>
 
 ## Advantages of release by module
 
@@ -44,9 +44,9 @@ and maintain our own alternative, to all
 <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.
+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>
 
 



Mime
View raw message