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

[cu...@apache.org]

Author: cumminsh
Date: Tue Jul 17 16:10:51 2012
New Revision: 1362552

URL: http://svn.apache.org/viewvc?rev=1362552&view=rev
Log:
Improved formatting, added David Jencks' profile idea

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=1362552&r1=1362551&r2=1362552&view=diff
==============================================================================
--- aries/site/trunk/content/development/releasingaries.mdtext (original)
+++ aries/site/trunk/content/development/releasingaries.mdtext Tue Jul 17 16:10:51 2012
@@ -37,24 +37,29 @@ of all Aries modules and their most rece
 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 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 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 api bundles release and have them
+    * 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
 projects, then close the staging repo and call for a vote.
-   * Bundles in the staging repo will need to compiled in a set order, which makes the verification script less useful.
-   * 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.
+    * Bundles in the staging repo will need to compiled in a set order, which makes the verification script less useful.
+    * 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**
+    * 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**
-   * 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 
-   * See below for extra instructions on releasing 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 
+    * See below for extra instructions on releasing from a branch
 
 ### How to deal with JIRA
 Before actually doing any releasing work through the list of bundles and understand what defects have been fixed