svn commit: r826127 - in /websites/staging/aries/trunk/content: ./ development/releasingaries.html

[bu...@apache.org]

Author: buildbot
Date: Tue Jul 17 16:14:42 2012
New Revision: 826127

Log:
Staging update by buildbot for aries

Modified:
    websites/staging/aries/trunk/content/   (props changed)
    websites/staging/aries/trunk/content/development/releasingaries.html

Propchange: websites/staging/aries/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue Jul 17 16:14:42 2012
@@ -1 +1 @@
-1362552
+1362555

Modified: websites/staging/aries/trunk/content/development/releasingaries.html
==============================================================================
--- websites/staging/aries/trunk/content/development/releasingaries.html (original)
+++ websites/staging/aries/trunk/content/development/releasingaries.html Tue Jul 17 16:14:42 2012
@@ -296,12 +296,12 @@ of all Aries modules and their most rece
 <h3 id="choosing-a-strategy-for-the-release">Choosing a strategy for the release</h3>
 <p>Even when releasing a large number of bundles, in Aries we release bundles individually. If there are dependencies
 between the bundles you want to release, you have three strategies for how to release them.
-<em> <strong>Release incrementally.</strong> 
+  * <strong>Release incrementally.</strong> 
     * Release bundles in dependency order, updating dependencies only after releases are promoted.
     * This has the advantage that trunk always builds cleanly.
     * The disadvantage is that each release needs to be open for voting for at least 72 hours, so the elapsed time for a large release can be very long.
     * The list may get fed up of voting on multiple vote threads, although the <a href="http://aries.apache.org/development/verifyingrelease.html">verification script</a> may help.
-</em> <strong>Release all at once, then patch up trunk, then fix trunk</strong>
+  * <strong>Release all at once, then patch up trunk, then fix trunk</strong>
     * Release api bundles release and have them
 uploaded to nexus, then upgrade the implementations  and all other
 components to use those releases, commit,  release those other
@@ -310,11 +310,12 @@ projects, then close the staging repo an
     * Trunk will be broken, unless you back out everything which you changed to use the released version back to using the old snapshot (<em>not</em> the new snapshot created by the release plugin). Then once the release has been promoted, change everything using the old snapshot back to using the released version.
     * Doing a release this way can really reduce the amount of time spent waiting for votes.
     * However, getting everything right without breaking trunk can be complex.
-<em> <strong>Release all at once, and use profiles to keep trunk building</strong>
+  * <strong>Release all at once, and use profiles to keep trunk building</strong>
     * This is similar to the second procedure, except instead of backing everything out, you just provide a maven profile which people can use until the release is promoted
     * Once the release is promoted, cleaning up is easy - just delete the profile
     * You will also need to temporarily change the Jenkins build instructions
-    * If people don't notice they need to build using a profile, they may be confused about why things are broken</em> <strong>Release from a branch</strong>
+    * If people don't notice they need to build using a profile, they may be confused about why things are broken
+  * <strong>Release from a branch</strong>
     * This is similar to the second procedure, except there's no need to patch trunk up to keep it compiling
     * You will need to merge the branch across once the release has been promoted, which is extra complexity
     * Doing mainline releases from branches plays havoc with git mirroring, so we promised to try and avoid doing it