aries-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cummi...@apache.org
Subject svn commit: r1362555 - /aries/site/trunk/content/development/releasingaries.mdtext
Date Tue, 17 Jul 2012 16:14:38 GMT
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 



Mime
View raw message