svn commit: r1362555 - /aries/site/trunk/content/development/releasingaries.mdtext

[cu...@apache.org]

Author: cumminsh
Date: Tue Jul 17 16:14:38 2012
New Revision: 1362555

URL: http://svn.apache.org/viewvc?rev=1362555&view=rev
Log:
Improved formatting

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

Modified: aries/site/trunk/content/development/releasingaries.mdtext
URL: http://svn.apache.org/viewvc/aries/site/trunk/content/development/releasingaries.mdtext?rev=1362555&r1=1362554&r2=1362555&view=diff
==============================================================================
--- aries/site/trunk/content/development/releasingaries.mdtext (original)
+++ aries/site/trunk/content/development/releasingaries.mdtext Tue Jul 17 16:14:38 2012
@@ -36,12 +36,12 @@ of all Aries modules and their most rece
 ### Choosing a strategy for the release
 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.
-* **Release incrementally.** 
+  * **Release incrementally.** 
     * 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 [verification script](http://aries.apache.org/development/verifyingrelease.html) may help.
-* **Release all at once, then patch up trunk, then fix trunk**
+  * **Release all at once, then patch up trunk, then fix trunk**
     * 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
@@ -50,12 +50,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 (*not* 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.
-* **Release all at once, and use profiles to keep trunk building**
+  * **Release all at once, and use profiles to keep trunk building**
     * 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
-* **Release from a branch**
+  * **Release from a branch**
     * 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