You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@aries.apache.org by bu...@apache.org on 2011/03/24 13:50:51 UTC
svn commit: r787460 -
/websites/staging/aries/trunk/content/development/releasingaries.html
Author: buildbot
Date: Thu Mar 24 12:50:51 2011
New Revision: 787460
Log:
Staging update by buildbot
Modified:
websites/staging/aries/trunk/content/development/releasingaries.html
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 Thu Mar 24 12:50:51 2011
@@ -282,255 +282,296 @@ Based on this, use the <a href="versionp
<p>Once the bundles are in the staging repository, start a vote on the release. After 72 hours close the vote. To complete
the release process it is necessary to copy the new bundles to the dist dir and update table on the web pages.</p>
<h2 id="releasing_a_distribution">Releasing a distribution</h2>
-<h2 id="releasing_the_samples">Releasing the samples.</h2>
-<h1 id="background_information_on_the_apache_release_process">Background information on the Apache Release process</h1>
-<p>To create a release you will need to create the release artifacts and move
+<p>A distribution is just a collection of Aries bundles which have already been released.
+The distribution is just a convenient way for consumers to download related bundles.
+There are three distributions:
+ * Blueprint
+ * Application (isolating framework)
+ * Application (non-isolating framework)</p>
+<h2 id="releasing_the_samples">Releasing the samples</h2>
+<p>The Aries samples are designed to work across all the Aries modules. Samples are released as a single
+module. All of the Aries dependencies are listed in the top level samples pom. In
+trunk, the version of all the dependencies should always point the SNAPSHOT versions
+in trunk. At release time these must all be modified to the latest released version of
+each bundle. <em>It is very important the versions are set <strong>only</strong> in the top level
+sample pom</em>. Both sub-modules and filtered resources need the version information, setting it in
+one place is the only way to avoid a mess.</p>
+<p>The best time to do a samples release is usually at the end of a bundle release when
+all of the bundle version information is up to date in aries_release_versions.txt. </p>
+
+<p>It is critically important that the samples are all tested before making release. Some have itests
+but others (blueprint) are only tested manually. In fact it's wise to run through
+a quick manual check for the blog and aries trader samples as the itests do not catch everything.
+
+# Background information on the Apache Release process
+
+To create a release you will need to create the release artifacts and move
then to various places (ultimately the Maven central repository). The Maven
-commands and general outline of the process looks like this:</p>
-<p><img alt="rel" src="AriesRelease.png" /></p>
-<p>The full maven commands are not shown - the intention is just to
+commands and general outline of the process looks like this:
+
+
+
+The full maven commands are not shown - the intention is just to
give an indication of which maven commands you will need to use to create
-release artifacts in different places.</p>
-<p>Performing a release is described in detail <a href="http://apache.org/dev/publishing-maven-artifacts.html">here</a>
+release artifacts in different places.
+
+Performing a release is described in detail [here](http://apache.org/dev/publishing-maven-artifacts.html)
. This document It covers all the steps listed above so on these pages we
-will only add things which are specific to the Apache Aries release. </p>
-<p>There are a few steps to the process:</p>
-<ol>
-<li>Discussion of the release and its content on the dev@aries mailing list.</li>
-<li>Creating and storing GPG keys</li>
-<li>Setting up your environment</li>
-<li>JIRA preparation</li>
-<li>Checking the release version of the bundle</li>
-<li>Checking release artifacts on your local system</li>
-<li>Creating a snapshot release </li>
-<li>Releasing to a staging repository (uses mvn release:prepare and mvn
-release:perform)</li>
-<li>Running a vote</li>
-<li>Promoting the release artifacts to the Apache release repository</li>
-<li>Making the release artifacts available from the Aries web pages</li>
-<li>What to do when people find problems with the release artifacts</li>
-</ol>
-<p>The best current documentation for releases is <a href="http://apache.org/dev/publishing-maven-artifacts.html">here</a>. It covers all the steps listed above so on
+will only add things which are specific to the Apache Aries release.
+
+There are a few steps to the process:
+
+1. Discussion of the release and its content on the dev@aries mailing list.
+ 1. Creating and storing GPG keys
+ 1. Setting up your environment
+ 1. JIRA preparation
+ 1. Checking the release version of the bundle
+ 1. Checking release artifacts on your local system
+ 1. Creating a snapshot release
+ 1. Releasing to a staging repository (uses mvn release:prepare and mvn
+release:perform)
+ 1. Running a vote
+ 1. Promoting the release artifacts to the Apache release repository
+ 1. Making the release artifacts available from the Aries web pages
+ 1. What to do when people find problems with the release artifacts
+
+The best current documentation for releases is [here](http://apache.org/dev/publishing-maven-artifacts.html). It covers all the steps listed above so on
these pages we will only add things which are specific to the Apache Aries
-release.</p>
-<p><a name="ReleasingAries-Discussionofthereleaseandit'scontentontheAriesmailinglist"></a></p>
-<h3 id="discussion_of_the_release_and_its_content_on_the_aries_mailing_list">Discussion of the release and its content on the Aries mailing list</h3>
-<p>Before starting off the release process it is essential to gain consensus
+release.
+
+<a name="ReleasingAries-Discussionofthereleaseandit'scontentontheAriesmailinglist"></a>
+### Discussion of the release and its content on the Aries mailing list
+Before starting off the release process it is essential to gain consensus
on the dev@aries list that this is the right time for a release and to
-agree its content. Allow at least a week for this discussion. </p>
-<p><a name="ReleasingAries-CreatingandstoringGPGkeys"></a></p>
-<h3 id="creating_and_storing_gpg_keys">Creating and storing GPG keys</h3>
-<p>For Aries your GPG key will need to be in this file:
+agree its content. Allow at least a week for this discussion.
+
+<a name="ReleasingAries-CreatingandstoringGPGkeys"></a>
+### Creating and storing GPG keys
+For Aries your GPG key will need to be in this file:
https://svn.apache.org/repos/asf/aries/KEYS (follow the
-instructions in the file) and checkin</p>
-<p><a name="ReleasingAries-Settingupyourenvironment"></a></p>
-<h3 id="setting_up_your_environment">Setting up your environment</h3>
-<p>Follow the general instructions linked to above. </p>
-<p><a name="ReleasingAries-Creatingabranchtoreleasefrom"></a></p>
-<h3 id="creating_a_branch_to_release_from">Creating a branch to release from</h3>
-<p>It is strongly recomended that releases are made from trunk and NEVER from a branch. But, if you have to release from a branch this is what
-you will need to do:</p>
-<div class="codehilite"><pre><span class="n">svn</span> <span class="n">copy</span> <span class="n">https:</span><span class="sr">//s</span><span class="n">vn</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">org</span><span class="sr">/repos/</span><span class="n">asf</span><span class="sr">/aries/</span><span class="n">trunk</span> <span class="o">\</span>
+instructions in the file) and checkin
+
+<a name="ReleasingAries-Settingupyourenvironment"></a>
+### Setting up your environment
+
+Follow the general instructions linked to above.
+
+<a name="ReleasingAries-Creatingabranchtoreleasefrom"></a>
+### Creating a branch to release from
+It is strongly recomended that releases are made from trunk and NEVER from a branch. But, if you have to release from a branch this is what
+you will need to do:
-<span class="n">https:</span><span class="sr">//s</span><span class="n">vn</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">org</span><span class="sr">/repos/</span><span class="n">asf</span><span class="sr">/aries/</span><span class="n">branches</span><span class="o">/</span><span class="mi">0</span><span class="o">.</span><span class="n">X</span><span class="o">-</span><span class="n">RCx</span> <span class="o">\</span>
+svn copy https://svn.apache.org/repos/asf/aries/trunk \
- <span class="o">-</span><span class="n">m</span> <span class="s">"Creating a release branch of /aries/trunk."</span>
-</pre></div>
+https://svn.apache.org/repos/asf/aries/branches/0.X-RCx \
+-m "Creating a release branch of /aries/trunk."
-<p>Where '0.X' is the number of the release.</p>
-<p>Checkout the new branch, for example, for the 0.2-incubating release:</p>
-<div class="codehilite"><pre><span class="n">svn</span> <span class="n">co</span> <span class="n">https:</span><span class="sr">//s</span><span class="n">vn</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">org</span><span class="sr">/repos/</span><span class="n">asf</span><span class="sr">/aries/</span><span class="n">branches</span><span class="o">/</span><span class="mf">0.2</span><span class="o">-</span><span class="n">RCx</span> <span class="n">aries</span><span class="o">-</span><span class="mf">0.2</span><span class="o">-</span><span class="n">candidate</span>
-</pre></div>
+Where '0.X' is the number of the release.
+Checkout the new branch, for example, for the 0.2-incubating release:
-<p><em>IMPORTANT</em> If you are using a branch to release you <strong>must</strong> edit the
-pom.xml for <strong>each</strong> bundle to change the SCM references to point to the
-branch and not to trunk. For example:</p>
-<div class="codehilite"><pre><span class="nt"><connection></span>scm:svn:http://svn.apache.org/repos/asf/aries/branches/0.2-RCx/parent<span class="nt"></connection></span>
+svn co https://svn.apache.org/repos/asf/aries/branches/0.2-RCx aries-0.2-candidate
-<span class="nt"><developerConnection></span>scm:svn:https://svn.apache.org/repos/asf/aries/branches/0.2-RCx/parent<span class="nt"></developerConnection></span>
+*IMPORTANT* If you are using a branch to release you **must** edit the
+pom.xml for **each** bundle to change the SCM references to point to the
+branch and not to trunk. For example:
-<span class="nt"><url></span>scm:svn:http://svn.apache.org/repos/asf/aries/branches/0.2-RCx/parent<span class="nt"></url></span>
-</pre></div>
+<connection>scm:svn:http://svn.apache.org/repos/asf/aries/branches/0.2-RCx/parent</connection>
+<developerConnection>scm:svn:https://svn.apache.org/repos/asf/aries/branches/0.2-RCx/parent</developerConnection>
-<p>The consequence of forgetting this is that the commands that create the
+<url>scm:svn:http://svn.apache.org/repos/asf/aries/branches/0.2-RCx/parent</url>
+
+The consequence of forgetting this is that the commands that create the
release (mvn release:prepare, mvn release:perform) will declare SUCCESS but
will not create a staging repository and will add stuff to the snapshot
-repository :-/.</p>
-<p>After taking the branch, change the pom versions in trunk to, say,
-0.3-incubating or whatever you want to call the next development version.</p>
-<p><a name="ReleasingAries-Checkingbundleversion"></a></p>
-<h3 id="checking_which_version_of_the_bundle_to_release">Checking which version of the bundle to release</h3>
-<p>If the Maven version of the bundle ends -SNAPSHOT then some change has been made which may require a release.
+repository :-/.
+
+After taking the branch, change the pom versions in trunk to, say,
+0.3-incubating or whatever you want to call the next development version.
+
+<a name="ReleasingAries-Checkingbundleversion"></a>
+### Checking which version of the bundle to release
+If the Maven version of the bundle ends -SNAPSHOT then some change has been made which may require a release.
To get a summary of the changes, use svn to compare with the most recently released tag,
-for example:</p>
-<div class="codehilite"><pre> <span class="n">svn</span> <span class="n">diff</span> <span class="n">https:</span><span class="sr">//s</span><span class="n">vn</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">org</span><span class="sr">/repos/</span><span class="n">asf</span><span class="sr">/aries/</span><span class="n">tags</span><span class="sr">/testsupport-0.3/</span> <span class="n">https:</span><span class="sr">//s</span><span class="n">vn</span><span class="o">.</span><span class="n">apache</span><span class="o">.</span><span class="n">org</span><span class="sr">/repos/</span><span class="n">asf</span><span class="sr">/aries/</span><span class="n">trunk</span><span class="sr">/testsupport/</span> <span class="o">--</span><span class="n">summarize</span>
-</pre></div>
+for example:
+svn diff https://svn.apache.org/repos/asf/aries/tags/testsupport-0.3/ https://svn.apache.org/repos/asf/aries/trunk/testsupport/ --summarize
-<p>In general, if no Java files have changed only the micro version of the bundle will need to be incremented on release. If Java
+In general, if no Java files have changed only the micro version of the bundle will need to be incremented on release. If Java
code has changed it is important to check the packageinfo files to see whether package versions have changed. If so
-these might lead to the requirement to increment the major or minor versions the bundle.</p>
-<p><a name="ReleasingAries-Checkingreleaseartifacts"></a></p>
-<h3 id="checking_release_artifacts">Checking release artifacts</h3>
-<p>Delete everything under ...org/apache/aries in your local
-Maven repo. For linux/Mac users you will find this under ~/.m2/repository/.</p>
-<p>Check that the code builds using the usual <a href="buildingaries.html">sequence</a>
- of commands, but add the following arguments to the 'mvn install' command:</p>
-<div class="codehilite"><pre><span class="n">mvn</span> <span class="n">install</span> <span class="o">-</span><span class="n">Papache</span><span class="o">-</span><span class="n">release</span> <span class="o">-</span><span class="n">DcreateChecksum</span><span class="o">=</span><span class="n">true</span>
-</pre></div>
-
-
-<p>This should build and install release artifacts in your local repo. </p>
-<p>Check the <a href="https://repository.apache.org/content/repositories/releases/org/apache/aries/parent/0.1-incubating/">0.1 release</a>
- to understand what files should be created.</p>
-<p>To perform legal checks, in each subproject, run:</p>
-<div class="codehilite"><pre><span class="n">mvn</span> <span class="n">rat:check</span> <span class="o">-</span><span class="n">fn</span>
-</pre></div>
+these might lead to the requirement to increment the major or minor versions the bundle.
+
+<a name="ReleasingAries-Checkingreleaseartifacts"></a>
+### Checking release artifacts
+Delete everything under ...org/apache/aries in your local
+Maven repo. For linux/Mac users you will find this under ~/.m2/repository/.
+
+Check that the code builds using the usual [sequence](buildingaries.html)
+ of commands, but add the following arguments to the 'mvn install' command:
+
+mvn install -Papache-release -DcreateChecksum=true
+This should build and install release artifacts in your local repo.
-<p>This will run through the project and its sub projects generating a file
+Check the [0.1 release](https://repository.apache.org/content/repositories/releases/org/apache/aries/parent/0.1-incubating/)
+ to understand what files should be created.
+
+To perform legal checks, in each subproject, run:
+
+mvn rat:check -fn
+
+This will run through the project and its sub projects generating a file
called rat.txt in each target directory.
The 'fn' means it will carry on even if it find a failure. To inspect the
-failures, use:</p>
-<div class="codehilite"><pre><span class="n">find</span> <span class="o">.</span> <span class="o">-</span><span class="n">name</span> <span class="n">rat</span><span class="o">.</span><span class="n">txt</span> <span class="o">|</span> <span class="n">xargs</span> <span class="nb">grep</span> <span class="o">\!\</span><span class="p">?</span><span class="o">\</span><span class="p">?</span>
-</pre></div>
-
-
-<p>This will pick out the failing file names. Some of the files that rat fails
-do not require an Apache license, eg MANIFEST.MF, but any <em>.java or </em>.js
-file does need one. As an alternative you can use 'mvn -Prat install'.</p>
-<p><a name="ReleasingAries-Creatingasnapshotrelease"></a></p>
-<h3 id="creating_a_snapshot_release">Creating a snapshot release</h3>
-<p>This is important to do when releasing from trunk as other bundles may want
-to continue to depend on the -SNAPSHOT version while the release is voted through.</p>
-<p>mvn deploy (check exact format)</p>
-<h3 id="jira_preparation">JIRA preparation</h3>
-<ul>
-<li>After initial release discussion on the mailing list you should have a list of JIRA issues that are required in the release. If not, the default assumption is 'everything that has been fixed since the last release'.</li>
-<li>Make sure that there is a JIRA component that matches the name of the release, if not, create one.</li>
-<li>Check through defects, make sure that anything that is included in the release has been closed. If there are open issues move them to the next release.</li>
-</ul>
-<p><a name="ReleasingAries-Creatingtherelease"></a></p>
-<h3 id="creating_the_release">Creating the release</h3>
-<p><a name="ReleasingAries-Creatingthereleaseartifactsinastagingrepository"></a></p>
-<h5 id="creating_the_release_artifacts_in_a_staging_repository">Creating the release artifacts in a staging repository</h5>
-<p>The release is
+failures, use:
+
+find . -name rat.txt | xargs grep \!\?\?
+
+This will pick out the failing file names. Some of the files that rat fails
+do not require an Apache license, eg MANIFEST.MF, but any *.java or *.js
+file does need one. As an alternative you can use 'mvn -Prat install'.
+
+<a name="ReleasingAries-Creatingasnapshotrelease"></a>
+### Creating a snapshot release
+This is important to do when releasing from trunk as other bundles may want
+to continue to depend on the -SNAPSHOT version while the release is voted through.
+
+mvn deploy (check exact format)
+
+### JIRA preparation
+ * After initial release discussion on the mailing list you should have a list of JIRA issues that are required in the release. If not, the default assumption is 'everything that has been fixed since the last release'.
+ * Make sure that there is a JIRA component that matches the name of the release, if not, create one.
+ * Check through defects, make sure that anything that is included in the release has been closed. If there are open issues move them to the next release.
+
+<a name="ReleasingAries-Creatingtherelease"></a>
+### Creating the release
+
+<a name="ReleasingAries-Creatingthereleaseartifactsinastagingrepository"></a>
+##### Creating the release artifacts in a staging repository
+
+The release is
created by releasing each bundle separately and in a specific order. It is
also desirable to maintain the same IP address for the entire process (the
staging repository is associated with your IP address, changing it results
-in the creation of a second staging repository).</p>
-<p>Short summary: Use a wired ether net connection and allow about 4 hours for
-the next few steps.</p>
-<p>From the top level directory in your branch run:</p>
-<div class="codehilite"><pre><span class="n">mvn</span> <span class="n">clean</span>
-</pre></div>
+in the creation of a second staging repository).
+
+Short summary: Use a wired ether net connection and allow about 4 hours for
+the next few steps.
+From the top level directory in your branch run:
-<p><em>Note</em> The prepare step will make some assumptions about the version of the
+mvn clean
+
+*Note* The prepare step will make some assumptions about the version of the
development stream that is left after the release has been made. When
releasing from a branch it may not be a good idea to accept the default for
this, it will very likely conflict with the development version in use in
-trunk.</p>
-<p>For each bundle that needs to be release perform the following commands:</p>
-<div class="codehilite"><pre><span class="n">Check</span> <span class="n">that</span> <span class="n">there</span> <span class="n">are</span> <span class="nb">no</span> <span class="n">depndencies</span> <span class="n">on</span> <span class="o">-</span><span class="n">SNAPSHOT</span> <span class="n">versions</span><span class="o">.</span>
-<span class="n">Ensure</span> <span class="n">that</span> <span class="n">everything</span> <span class="n">is</span> <span class="n">committed</span> <span class="n">in</span> <span class="n">SVN</span>
-<span class="n">mvn</span> <span class="n">release:prepare</span> <span class="o">-</span><span class="n">Papache</span><span class="o">-</span><span class="n">release</span> <span class="o">-</span><span class="n">DpreparationGoals</span><span class="o">=</span><span class="s">"clean install"</span>
-<span class="n">mvn</span> <span class="n">release:perform</span> <span class="o">-</span><span class="n">Papache</span><span class="o">-</span><span class="n">release</span>
-</pre></div>
+trunk.
+
+For each bundle that needs to be release perform the following commands:
+
+Check that there are no depndencies on -SNAPSHOT versions.
+ Ensure that everything is committed in SVN
+ mvn release:prepare -Papache-release -DpreparationGoals="clean install"
+ mvn release:perform -Papache-release
+* Note 1: Use the -DdryRun option to check that release-prepare works.
+ * Note 2: mvn release:prepare makes and commits changes in SVN.
+ * Note 3: mvn release:clean will do *most* of the cleaning up in the event of failures.
-<ul>
-<li>Note 1: Use the -DdryRun option to check that release-prepare works.</li>
-<li>Note 2: mvn release:prepare makes and commits changes in SVN. </li>
-<li>Note 3: mvn release:clean will do <em>most</em> of the cleaning up in the event of failures.</li>
-</ul>
-<p>This will put release artifacts into an Apache <a href="https://repository.apache.org/index.html#view-repositories;staging.html">staging repository </a>. You will need to log in to see it.
+This will put release artifacts into an Apache [staging repository ](https://repository.apache.org/index.html#view-repositories;staging.html). You will need to log in to see it.
If nothing appears in a staging repo you should stop here and work out why.
If you have made a mistake it's quite easy to revert. The release
commands make and commit changes to the project's pom.xml files and they
create a tag in SVN. To revert the changes you will need to revert the
-pom.xml files and delete the tag from svn.</p>
-<p>If you are in Europe the mvn release:prepare command almost always fails at
-the last step, with a message like:</p>
-<div class="codehilite"><pre><span class="k">[ERROR]</span>
- <span class="err">BUILD</span> <span class="err">FAILURE</span>
-<span class="k">[INFO]</span>
- <span class="err">------------------------------------------------------------------------</span>
-<span class="k">[INFO]</span>
- <span class="err">Unable</span> <span class="err">to</span> <span class="err">tag</span> <span class="err">SCM</span>
-<span class="err">Provider</span> <span class="err">message:</span>
-<span class="err">The</span> <span class="err">svn</span> <span class="err">tag</span> <span class="err">command</span> <span class="err">failed.</span>
-<span class="err">Command</span> <span class="err">output:</span>
-<span class="err">svn:</span> <span class="err">No</span> <span class="err">such</span> <span class="err">revision</span> <span class="err">936951</span>
-</pre></div>
+pom.xml files and delete the tag from svn.
+If you are in Europe the mvn release:prepare command almost always fails at
+the last step, with a message like:
-<p>This is due to the SVN mirroring in place between Europe and the master in
+[ERROR]
+ BUILD FAILURE
+ [INFO]
+ ------------------------------------------------------------------------
+ [INFO]
+ Unable to tag SCM
+ Provider message:
+ The svn tag command failed.
+ Command output:
+ svn: No such revision 936951
+
+This is due to the SVN mirroring in place between Europe and the master in
the US. When you make a commit, it isn't immediately available in Europe to
svn up to. Just wait 10 secs and repeat the mvn release:prepare command for
-it to restart where it left off.</p>
-<p><a name="ReleasingAries-Closingthestagingrepository"></a></p>
-<h5 id="closing_the_staging_repository">Closing the staging repository</h5>
-<p>After checking that the staging repository contains the artifacts that you
+it to restart where it left off.
+
+<a name="ReleasingAries-Closingthestagingrepository"></a>
+##### Closing the staging repository
+After checking that the staging repository contains the artifacts that you
expect you should close the staging repository. This will make it available
-so that people can check the release.</p>
-<p><a name="ReleasingAries-Runningthevote(s)"></a></p>
-<h3 id="running_the_vote">Running the vote.</h3>
-<p>At this
-point you should write two notes to the dev@aries.apache.org mailing list.</p>
-<ul>
-<li>Subject [VOTE]
- Apache Aries release candidate 0N</li>
-</ul>
-<p>The the source archive files should be explicitly called out by release
+so that people can check the release.
+
+<a name="ReleasingAries-Runningthevote(s)"></a>
+### Running the vote.
+
+At this
+point you should write two notes to the dev@aries.apache.org mailing list.
+
+* Subject \[VOTE\]
+ Apache Aries release candidate 0N
+
+The the source archive files should be explicitly called out by release
manager in any release vote. From an Apache legal standpoint, this is what
the project is "releasing" and what the community should be voting on. In
-this <a href="devlistvote.txt">sample note</a>
-, there is a link to each modules' source*.zip file.</p>
-<ul>
-<li>Subject [DISCUSS]
- Apache Aries release candidate 0X</li>
-</ul>
-<p>The content should just indicate that the note starts a thread to discuss
-the Aries release.</p>
-<p>After 72 hours, if no problems have been found in the release artifacts,
+this [sample note](devlistvote.txt)
+, there is a link to each modules' source*.zip file.
+
+* Subject \[DISCUSS\]
+ Apache Aries release candidate 0X
+
+The content should just indicate that the note starts a thread to discuss
+the Aries release.
+
+After 72 hours, if no problems have been found in the release artifacts,
the dev@aries vote can be summarised and closed. Note that at least three
-+1 votes from Aries PMC members are required. </p>
-<p>Finally - ensure that the file aries_release_version.txt is completely up to date and accurate.
-You will use this file in the following steps to help build the release web pages.</p>
-<p><a name="ReleasingAries-Promotingthereleaseartifacts"></a></p>
-<h3 id="promoting_the_release_artifacts">Promoting the release artifacts</h3>
-<p>From the <a href="https://repository.apache.org/index.html#stagingRepositories">Nexus pages</a>
++1 votes from Aries PMC members are required.
+
+Finally - ensure that the file aries_release_version.txt is completely up to date and accurate.
+You will use this file in the following steps to help build the release web pages.
+
+<a name="ReleasingAries-Promotingthereleaseartifacts"></a>
+### Promoting the release artifacts
+From the [Nexus pages](https://repository.apache.org/index.html#stagingRepositories)
, select the staging repository and select 'release' from the top menu.
This moves the release artifacts into an Apache releases repository, from
-there they will be automatically moved to the Maven repository.</p>
-<p><a name="ReleasingAries-MakingthereleaseartifactsavailablefromtheArieswebpages."></a></p>
-<h3 id="making_the_release_artifacts_available_from_the_aries_web_pages">Making the release artifacts available from the Aries web pages.</h3>
-<p>Anything that is to be downloaded must be put in
+there they will be automatically moved to the Maven repository.
+
+<a name="ReleasingAries-MakingthereleaseartifactsavailablefromtheArieswebpages."></a>
+### Making the release artifacts available from the Aries web pages.
+Anything that is to be downloaded must be put in
/www/www.apache.org/dist/aries on minotaur. Don't forget to changes the file permissions to '664' so that other
members of the group can access them. The distributions are
-archived here /www/archive.apache.org/dist/aries.</p>
-<p>First, delete the previous distribution from the distribution directory.
+archived here /www/archive.apache.org/dist/aries.
+
+First, delete the previous distribution from the distribution directory.
Download the release artifacts This is best done using a script, the script can be generated uing
-the perl script download_release_artifacts.pl. </p>
-<p>Next, update the Aries Downloads pages to refer to the new artifacts.</p>
-<h3 id="tidying_up_tasks">Tidying up tasks</h3>
-<ul>
-<li>Get the compliance tests run</li>
-<li>Release notes</li>
-<li>Release the component in JIRA (manage components), check the JIRA release notes.</li>
-</ul>
-<p><a name="ReleasingAries-Whattodowhenpeoplefindproblemswiththerelease"></a></p>
-<h3 id="what_to_do_when_people_find_problems_with_the_release">What to do when people find problems with the release</h3>
-<ul>
-<li>Cancel the vote [CANCELLED] [VOTE]</li>
-<li>Clean up, fix and re-release.
+the perl script download_release_artifacts.pl.
+
+Next, update the Aries Downloads pages to refer to the new artifacts.
+
+### Tidying up tasks
+ * Get the compliance tests run
+ * Release notes
+ * Release the component in JIRA (manage components), check the JIRA release notes.
+
+<a name="ReleasingAries-Whattodowhenpeoplefindproblemswiththerelease"></a>
+### What to do when people find problems with the release
+ * Cancel the vote \[CANCELLED\] \[VOTE\]
+ * Clean up, fix and re-release.
The good news here is that it isn't necessarily essential to re-release
-every module. </li>
-</ul></div>
+every module.</div>
<!-- Content -->
</td>
</tr>